# 1. Hint 机制，MySQL 的 USE INDEX、FORCE INDEX、SQL Server 的 OPTION(RECOMPILE)？ A FORCE INDEX 在索引不适配时仍强制生效且零代价 B OPTION(RECOMPILE) 会复用旧计划 C USE INDEX 是可被忽略的建议，FORCE INDEX 是强制；OPTION(RECOMPILE) 每次执行重新编译以规避参数嗅探，但增加编译开销 ✓ 正确答案 D USE INDEX 与 FORCE INDEX 语义完全相同
# 2. MySQL 的 prepared statement 与 SQL 缓存？ A PREPARE 阶段完成解析、优化与计划生成，EXECUTE 阶段绑定参数复用计划，且参数与 SQL 分离可防注入 ✓ 正确答案 B MySQL 8.0 仍依赖 query cache 加速查询 C prepared statement 会强制全表扫描 D prepared statement 每次执行都重新解析
# 3. PostgreSQL 中无原生 Hint 的解决，pg_hint_plan 扩展？ A pg_hint_plan 无需安装即可生效 B Hint 可以永久替代统计调优 C PG 内置原生 Hint 语法 D pg_hint_plan 通过 planner hook 在规划阶段应用 /*+ */ 注释中的提示，需加载扩展且 SQL 改写后可能静默失效 ✓ 正确答案
# 4. PostgreSQL 的 prepared statement 与 generic plan，何时使用自定义计划？ A plan_cache_mode 只影响 pg_hint_plan B PG 总是使用 generic plan C PG 前 5 次执行用 custom plan 试探，之后 generic plan 代价不超过 custom 的 1.1 倍时固定 generic plan，倾斜数据下可失配 ✓ 正确答案 D custom plan 不考虑参数值
# 5. 计划缓存的失效（Invalidation），表结构变更、统计信息更新？ A 表结构变更、统计信息更新、权限与影响计划的 GUC 变更都会使相关缓存计划失效，SQL Server 按数据变化阈值触发重编译 ✓ 正确答案 B 索引增删不影响缓存计划 C 统计更新永远不会触发重编译 D 计划缓存只在服务器重启时失效
# 6. 计划缓存（Plan Cache）的实现，参数化查询的复用？ A 参数化使不同参数值共享同一计划，SQL Server 支持自动/强制参数化，PG 靠 PREPARE 复用，非参数化 SQL 会导致缓存膨胀 ✓ 正确答案 B 计划缓存键包含具体参数值 C 参数化会降低缓存命中率 D 只有 MySQL 有计划缓存
# 7. PostgreSQL 扩展查询协议下的 prepared statement，Parse/Bind/Execute 如何复用解析与规划结果，与简单查询协议的性能差异？ A Execute 阶段完成语法解析 B Parse 结果可被多次 Bind/Execute 复用，避免重复解析与规划，高频短查询下扩展协议规划开销显著低于简单协议 ✓ 正确答案 C Bind 阶段会重新解析 SQL D 简单协议比扩展协议规划开销更小
# 8. 参数嗅探（Parameter Sniffing）问题，第一次执行参数决定后续所有执行的计划？ A RECOMPILE 会提高计划复用率 B 参数嗅探只影响写入性能 C OPTIMIZE FOR UNKNOWN 会嗅探具体参数值 D 参数嗅探指首次执行参数决定缓存计划的估算，数据倾斜时该计划可能不适配后续参数，可用 RECOMPILE 或 OPTIMIZE FOR UNKNOWN 缓解 ✓ 正确答案
# 9. 参数嗅探的解决方案，OPTIMIZE FOR UNKNOWN、RECOMPILE？ A RECOMPILE 没有任何编译开销 B OPTIMIZE FOR UNKNOWN 忽略具体参数值、按默认密度估算生成稳健但非最优的计划，RECOMPILE 每次执行重新编译贴合当前参数 ✓ 正确答案 C 参数嗅探只存在于 MySQL D OPTIMIZE FOR UNKNOWN 会用嗅探到的参数值
# 10. OPTIMIZE FOR UNKNOWN 的实现？ A 它把参数值固定为 0 估算 B OPTIMIZE FOR UNKNOWN 按列的平均密度估算选择率、跳过直方图定位，本质与 PG 的 generic plan 一致，但严重倾斜时仍可能失配 ✓ 正确答案 C 它只影响编译速度不影响估算 D 它仍然使用嗅探到的参数值
# 11. SQL Server OPTION(RECOMPILE)？ A 高频语句最适合 RECOMPILE B 它只在首次执行时生效 C 它把计划缓存起来供后续复用 D OPTION(RECOMPILE) 每次执行重新编译生成贴合当前参数的计划，适合低频且计划敏感的语句，但高频滥用会增加编译开销 ✓ 正确答案
# 12. prepared statement 的缓存生命周期与内存管理，会话级 PREPARE 在连接池复用下的残留与失效场景，缓存条目过多时如何淘汰与控制内存占用？ A prepared statement 跨会话全局共享 B 连接池复用下 DDL 会使旧 prepared statement 失效，应用需捕获异常重新 PREPARE，条目过多可用 max_prepared_stmt_count 等上限控制 ✓ 正确答案 C 缓存条目过多时数据库会自动清理且无副作用 D PG 的 prepared statement 在会话结束后仍长期保留
# 13. FORCE INDEX 的适用场景，MySQL 统计信息失真或连接顺序失控时强制索引的代价，PostgreSQL 无同类 Hint 时如何通过统计信息与规划参数实现？ A FORCE INDEX 永远是最优解 B PG 提供原生 FORCE INDEX 语法 C FORCE INDEX 适合统计失真时的临时止血，但会锁死计划并掩盖根因，PG 侧应先刷新统计、建扩展统计、调 cost 参数再考虑 Hint ✓ 正确答案 D 强制索引不影响后续索引维护
# 14. Hint 与优化器的协同？ A Hint 通过裁剪搜索空间引导优化器，建议型 Hint 在代价不优时可能被忽略，对象名不一致或视图合并会导致静默失效 ✓ 正确答案 B 子查询展开后 Hint 依然精确匹配原对象 C Hint 会完全绕过代价函数 D Hint 一旦书写必然生效
# 15. 参数化查询与字面量查询的取舍，为什么生产库建议强制参数化（force_parameterize/cursor_sharing），何时必须保留字面量（数据倾斜严重）？ A 直方图对参数化查询完全无效 B 参数化会降低缓存命中率 C 强制参数化提升计划复用与缓存命中，但计划"平均化"在倾斜数据下可能失配，需为倾斜值保留字面量分支 ✓ 正确答案 D 字面量查询在任何场景都优于参数化
# 16. 计划缓存的内存与监控，如何查看计划缓存命中率、大小与淘汰，SQL Server 的 plan cache 压力如何诊断？ A 非参数化 SQL 会产生大量一次性计划挤占缓存，可用 sys.dm_exec_query_stats 观察重编译次数并配合强制参数化治理 ✓ 正确答案 B 计划缓存不存在内存压力 C 重编译次数与统计更新无关 D 缓存命中率 100% 时无需关注计划质量
# 17. Oracle SQL Plan Management（SPM）与 SQL Profile，如何固定稳定计划并在计划变化时灰度验证，与 PostgreSQL 的稳定性手段有何对应？ A SPM 把新计划先放入未接受池，经演进验证达标后才提升为 accepted，实现计划变化的灰度验证，SQL Profile 用于固定特定形态计划 ✓ 正确答案 B SQL Profile 是硬件配置 C PG 提供原生 SPM 功能 D SPM 会立即使用任何新计划
# 18. 统计信息对计划缓存的影响，统计更新后为何需要主动失效缓存（RECOMPILE/Query Store），生产变更时如何控制计划抖动？ A 重编译没有任何成本 B 统计更新会使基于旧统计的缓存计划失效，SQL Server 按行数变化阈值自动触发重编译，PG 的 generic plan 在统计变化后重新评估 ✓ 正确答案 C PG 的缓存计划永不更新 D 统计更新不影响缓存计划
# 19. Oracle 的 Hint 语法？ A Oracle Hint 永远生效不可忽略 B Hint 写在哪一行都可以 C Oracle Hint 写在 /*+ */ 注释中紧跟 SELECT 之后，对象名须与语句别名一致否则被静默忽略，10g 起 RBO 已废弃 ✓ 正确答案 D RULE Hint 在 19c 仍可用
# 20. 分布式数据库中的 Hint 与计划缓存，TiDB/StarRocks 等分布式执行中 Hint 的作用范围与缓存粒度与单机数据库有何差异？ A 分布式 Hint 与单机完全相同 B 分布式计划缓存永不失效 C 分布式数据库中 Hint 更多是局部约束，计划缓存按语句与 schema 版本管理，统计按 region 采样误差更大、抖动概率更高 ✓ 正确答案 D 分布式数据库不需要统计信息
