# 1. 服务端预编译与客户端预编译的差异，MySQL 默认客户端预编译？ A 客户端预编译也能复用服务器端执行计划，效果与服务端预编译完全相同 B 服务端预编译让服务器缓存解析结果与执行计划，客户端预编译仅做参数分离，MySQL 默认使用客户端预编译以规避连接池复用下的缓存失效 ✓ 正确答案 C MySQL 默认采用服务端预编译，所有语句都会缓存执行计划 D 服务端预编译生成的执行计划与连接无关，可被任意连接复用
# 2. 绑定变量（Bind Variables）的执行计划缓存影响？ A 绑定变量使 SQL 文本稳定从而命中计划缓存，降低硬解析开销，但优化器无法针对具体参数值做特定优化 ✓ 正确答案 B 绑定变量与执行计划缓存无关，只影响网络传输大小 C 使用绑定变量一定会导致执行计划变差 D 不绑定变量时计划缓存命中率更高
# 3. 预编译语句（PreparedStatement）的优势，防 SQL 注入、执行计划复用？ A 参数值会被当作 SQL 的一部分解析，因此仍有注入风险 B PreparedStatement 只能防止注入，无法复用执行计划 C 参数与 SQL 在协议层分离，参数不被当作 SQL 解析，从而防止注入并保持 SQL 文本稳定以复用执行计划 ✓ 正确答案 D PreparedStatement 与字符串拼接 SQL 在性能上完全没有区别
# 4. 多语句执行（Multi-Statements）的安全风险，SQL 注入？ A 参数化查询可以完全防御多语句注入 B 多语句执行与注入无关，是安全的 C 多语句执行让单条语句更原子、更安全 D 多语句执行扩大了注入攻击面，攻击者可在合法查询后追加危险语句，默认应关闭并配合参数化查询 ✓ 正确答案
# 5. 预编译语句的执行计划何时失效（表结构变更、统计更新）与数据库端 plan cache 管理 A 只有 SQL 文本变化才会使计划失效 B 执行计划一经生成就永不失效 C 表结构变更、统计更新等会使预编译语句的执行计划失效，数据库会重新解析并生成新计划 ✓ 正确答案 D 统计更新不会影响执行计划
# 6. 批量 INSERT 多值（Multi-VALUES INSERT）的性能？ A 多值 INSERT 减少网络往返、解析与日志开销以提升吞吐，但受 max_allowed_packet 与事务规模限制需分批 ✓ 正确答案 B 多值 INSERT 与逐条 INSERT 性能完全相同 C 多值 INSERT 单条语句可以无限大，不受任何限制 D 多值 INSERT 无法被 JDBC 批量改写
# 7. 服务端预编译语句在连接池/PgBouncer 复用下的生命周期，为什么需要显式 DEALLOCATE 或按连接缓存？MySQL 的 useServerPrepStmts 如何控制？ A 预编译语句与创建它的连接绑定，连接池复用需显式 DEALLOCATE 或按连接缓存，MySQL 用 useServerPrepStmts 控制是否启用服务端预编译 ✓ 正确答案 B 预编译语句与连接无关，可被任意连接复用 C 连接池下预编译语句永远不需要释放 D useServerPrepStmts 与预编译语句生命周期无关
# 8. 协议层批量写入，executeBatch 与多值 INSERT 在 MySQL 文本协议/二进制协议下分别如何减少网络往返与解析开销？ A 二进制协议比文本协议更慢，因为需要转义 B executeBatch 减少往返次数，多值 INSERT 合并语句，二进制协议以类型编码减少转义与解析开销 ✓ 正确答案 C 多值 INSERT 会增加网络往返次数 D executeBatch 与多值 INSERT 无法结合使用
# 9. MySQL 文本协议与二进制预处理协议（COM_STMT_PREPARE/EXECUTE）的差异？二进制协议对日期/浮点/二进制字段的编解码有何优势？ A 文本协议对二进制字段更高效，因为无需转义 B 二进制协议按类型原生编码，免转义且避免文本转换，对日期、浮点、二进制字段更高效、精度更高 ✓ 正确答案 C 两种协议在编解码上完全等价 D 二进制协议必须对参数做文本转义
# 10. 管道化（Pipelining）的应用，MySQL 8.0、PostgreSQL 14？ A 管道化无需考虑错误处理 B 管道化会显著增加每条语句的延迟 C 管道化只对本地网络有效，对高 RTT 无收益 D 管道化允许连续发送多条请求减少网络往返延迟，但需处理错误定位与事务边界问题 ✓ 正确答案
# 11. MySQL JDBC 的 cachePrepStmts 参数与性能？ A cachePrepStmts 开启后所有 SQL 都会变慢 B cachePrepStmts 只影响结果集大小，与预编译无关 C cachePrepStmts 缓存预编译语句对象以减少重复解析，与 useServerPrepStmts 配合可复用服务端预编译并提升高频 SQL 性能 ✓ 正确答案 D cachePrepStmts 与 useServerPrepStmts 互斥，不能同时开启
# 12. 预编译语句的批量执行（addBatch）与性能？ A executeBatch 无法一次提交多条参数 B addBatch 与逐条执行性能完全相同 C 批大小越大越好，无需任何权衡 D addBatch 打包参数、executeBatch 一次提交减少往返与解析，但需权衡批大小与错误处理粒度 ✓ 正确答案
# 13. useServerPrepStmts 与 cachePrepStmts 组合下 SQL 文本是否仍带参数（? 占位符）及安全意义 A 启用 useServerPrepStmts 后 SQL 文本不再带占位符 B SQL 文本始终带 ? 占位符，参数作为数据传递，cachePrepStmts 只影响缓存不改变占位符语义 ✓ 正确答案 C cachePrepStmts 会去掉 SQL 中的占位符 D 客户端替换参数等同于把参数拼进 SQL 文本，存在注入风险
# 14. ORM 与预编译的交互，MyBatis/JPA 的 #{} 与 ${} 如何映射到绑定变量，为什么 ${} 拼接存在注入风险，动态 SQL 如何保持计划复用？ A #{} 映射为绑定变量安全且可复用计划，${} 直接拼接 SQL 文本存在注入风险 ✓ 正确答案 B #{} 与 ${} 完全等价，都防注入 C ${} 比 #{} 更安全，因为不会改变 SQL 结构 D 动态 SQL 无法复用任何执行计划
# 15. 预编译语句的监控与诊断，如何观测服务端预编译的命中率、缓存条目与失效原因，COM_STMT_PREPARE 语句量异常说明什么？ A COM_STMT_PREPARE 偏大说明预编译未按预期复用，需排查缓存配置与 SQL 文本稳定性 ✓ 正确答案 B COM_STMT_PREPARE 偏大说明预编译复用效果很好 C 预编译命中率无法通过任何指标观测 D 缓存失效与连接池无关
# 16. 管道化（pipelining）的工程边界，MySQL 8.0/PostgreSQL 14 管道化对批处理与往返延迟的收益，与事务边界、错误处理的交互？ A 管道化适合强依赖前序结果的操作 B 管道化降低高 RTT 批量延迟，但错误处理粒度变粗且需明确事务边界，适合大量独立、幂等的小操作 ✓ 正确答案 C 管道化无需处理错误与事务边界 D 管道化对所有操作都无条件适用
# 17. 预编译语句与分库分表中间件的兼容，ShardingSphere/MyCat 下服务端预编译如何被改写，绑定参数与路由字段的匹配如何处理？ A 中间件无需解析参数，可随意路由 B 中间件需解析绑定参数以确定分片，改写 SQL 后需重新匹配参数与占位符顺序 ✓ 正确答案 C 服务端预编译在中间件下无需任何处理 D 分片键永远无法作为绑定参数传入
# 18. MySQL allowMultiQueries 与 PostgreSQL 多语句协议的差异？批量执行时各自的注入面与限制？ A 两种协议在注入面与限制上完全相同 B MySQL 默认开启多语句，PostgreSQL 永远禁止多语句 C MySQL allowMultiQueries 需显式开启、默认关闭，PostgreSQL 扩展协议禁止多语句，两者多语句开启时都会扩大注入面 ✓ 正确答案 D PostgreSQL 扩展协议天然支持多语句
# 19. 批量插入的 SQL 大小上限（max_allowed_packet）与分批策略 A 超过 max_allowed_packet 只是稍慢，不会失败 B 批量插入的 SQL 大小不受任何限制 C 批量插入 SQL 不能超过 max_allowed_packet，需按行大小估算批大小并留安全余量，同时兼顾事务与锁压力 ✓ 正确答案 D 分批只考虑行数，无需考虑字节大小
