# 1. IN/EXISTS 改写为 JOIN 的等价条件与性能差异？ A IN 改写为 JOIN 时无需考虑去重问题。 B 子查询含聚合时优化器最容易展开。 C EXISTS 子查询永远无法改写为 JOIN。 D 优化器能自动展开子查询时，IN/EXISTS 与 JOIN 性能接近。 ✓ 正确答案
# 2. NOT IN 改写为 NOT EXISTS 的 NULL 陷阱？ A NOT IN 在子查询含 NULL 时行为与 NOT EXISTS 完全一致。 B NOT EXISTS 对 NULL 处理是有问题的。 C NOT IN 遇到子查询中的 NULL 时结果可能为空，称为 NULL 陷阱。 ✓ 正确答案 D NULL 不影响任何比较运算。
# 3. 子查询展开（Subquery Unnesting），将子查询转为 JOIN 提升优化器能力？ A 子查询展开把子查询从逐行执行转为 JOIN/半连接，扩大优化空间。 ✓ 正确答案 B 子查询展开总是成功，无任何限制。 C 子查询展开会降低优化器能力。 D 子查询展开只适用于 MySQL。
# 4. 标量子查询改写为 LEFT JOIN 的性能？ A 标量子查询永远比 LEFT JOIN 快。 B 标量子查询改写为 LEFT JOIN 通常能利用连接优化，避免逐行执行。 ✓ 正确答案 C LEFT JOIN 改写会改变 NULL 语义。 D 标量子查询无法改写为连接。
# 5. 相关子查询的优化，去相关（Decorrelation）的代价？ A 去相关会降低查询正确性。 B 去相关总是免费，无任何代价。 C 相关子查询无法去相关。 D 去相关将相关子查询转为连接，避免逐行执行，但可能引入去重等代价。 ✓ 正确答案
# 6. 谓词下推（Predicate Pushdown）的优化，尽早过滤减少数据量？ A 谓词下推把过滤条件推迟到最后。 B 谓词下推把过滤条件尽量下沉到扫描层，尽早减少数据量。 ✓ 正确答案 C 谓词下推会增加中间结果。 D 谓词下推只适用于单表查询。
# 7. 派生表（Derived Table）的优化器合并（Derived Merge）？ A 含聚合的派生表最容易合并。 B 派生表总是被物化，无法合并。 C 派生表合并把派生表内容展开进外层查询，避免物化，通常更高效。 ✓ 正确答案 D 派生表合并会降低优化能力。
# 8. 标量子查询改写为 JOIN？ A LEFT JOIN 与标量子查询的 NULL 语义不同。 B 标量子查询改写为 JOIN 一定更快且无需去重。 C 标量子查询改写为 JOIN 需保证子查询返回单行，否则可能放大行数。 ✓ 正确答案 D 标量子查询无法改写为 JOIN。
# 9. 相关子查询的执行次数（在执行计划与 SQL 优化范畴内）？ A 相关子查询总是只执行一次。 B 未去相关的相关子查询每外层行执行一次，外层行数大时代价很高。 ✓ 正确答案 C 去相关会增加子查询执行次数。 D 相关子查询执行次数与外层行数无关。
# 10. Hash Aggregate 的内存占用，哈希表超出 work_mem 时落盘？ A HashAggregate 的哈希表不受 work_mem 限制。 B HashAggregate 不使用哈希表。 C work_mem 不影响 HashAggregate。 D 哈希表超出 work_mem 时会落盘，性能下降。 ✓ 正确答案
# 11. work_mem 参数对排序的影响，默认 4MB，复杂查询需上调？ A work_mem 默认 4MB，是全局共享上限。 B work_mem 只影响连接池。 C work_mem 是每个操作实例的限额，复杂查询可上调但需评估并发内存。 ✓ 正确答案 D work_mem 无法修改。
# 12. Sort 节点的 EXPLAIN 解读？ A Sort Method 为 external merge 表示排序在内存完成。 B ORDER BY 列有索引时也必然出现 Sort 节点。 C Sort Key 反映 ORDER BY 列，Sort Method 反映内存/磁盘排序。 ✓ 正确答案 D Sort 节点信息无法用于优化。
# 13. MySQL 8.0 并行查询的应用场景，SELECT ... FOR UPDATE？ A MySQL 8.0 并行 read 支持所有加锁查询。 B SELECT ... FOR UPDATE 因涉及锁语义，不适合并行 read。 ✓ 正确答案 C 并行 read 只适用于写操作。 D MySQL 并行查询能力强于 PostgreSQL 的并行查询。
# 14. PostgreSQL JIT 的应用，表达式求值、聚合函数、tuple deforming？ A JIT 只对简单查询有效。 B JIT 通过 LLVM 编译表达式、聚合、tuple deforming 等热路径加速执行。 ✓ 正确答案 C JIT 没有编译开销。 D JIT 只影响 I/O 不涉及 CPU。
# 15. PostgreSQL 中 max_parallel_workers、max_parallel_workers_per_gather 参数？ A max_parallel_workers 是单查询 worker 上限。 B max_parallel_workers_per_gather 是单个查询的 worker 上限，全局 worker 总和受 max_parallel_workers 限制。 ✓ 正确答案 C 两个参数互不影响。 D 并行度只受表大小影响。
# 16. CTE 多次引用的代价，物化避免重复计算但需物化一次？ A CTE 无法物化。 B 物化 CTE 总是无代价。 C CTE 只引用一次时物化收益最大。 D 物化 CTE 可避免多次引用时重复计算，但需一次性构建代价。 ✓ 正确答案
# 17. CTE 的内联（Inline）与物化（Materialized）选择，PostgreSQL 12+ 默认内联？ A 物化总是优于内联。 B PostgreSQL 12+ 总是物化 CTE。 C 内联是优化屏障，无法与外层合并。 D PostgreSQL 12+ 默认对只引用一次的 CTE 内联，而非总是物化。 ✓ 正确答案
# 18. CTE 与子查询的执行计划差异（在执行计划与 SQL 优化范畴内）？ A CTE 与子查询永远计划相同。 B PostgreSQL 11 前 CTE 物化是优化屏障，12+ 默认对单次引用 CTE 内联。 ✓ 正确答案 C 子查询总是被物化。 D CTE 无法被内联。
# 19. CTE 的 EXPLAIN 解读？ A CTE 物化时无任何节点。 B CTE 内联时有 CTE Scan 节点。 C CTE 物化时计划中出现 CTE Scan 节点，内联时直接展开。 ✓ 正确答案 D CTE 无法从 EXPLAIN 判断。
# 20. PostgreSQL 12+ 的 CTE 行为？ A PostgreSQL 12+ 默认总是物化 CTE。 B PostgreSQL 12+ 默认对单次引用的 CTE 内联，消除优化屏障。 ✓ 正确答案 C CTE 内联无法与外层做谓词下推。 D PostgreSQL 12+ 的 CTE 行为与 11 完全相同。
# 21. 直方图的更新频率（在执行计划与 SQL 优化范畴内）？ A 直方图由 ANALYZE 采集，数据变化后需重新 ANALYZE 保持准确。 ✓ 正确答案 B 直方图是静态的，永不更新。 C 直方图只影响排序不影响行数估算。 D 直方图更新频率与优化无关。
# 22. Buffer Pool 的 LRU-K 算法，热点页缓存？ A LRU-K 不适用数据库缓存。 B LRU-K 与普通 LRU 完全一样。 C LRU-K 会把顺序扫描页放入热区。 D LRU-K 通过记录访问历史避免单次访问污染，保护热点页。 ✓ 正确答案
# 23. 查询结果缓存（Result Cache）的实现，内存中缓存哈希键查询？ A Result Cache 按参数键哈希缓存结果，重复参数查询直接命中。 ✓ 正确答案 B Result Cache 缓存所有查询结果，无内存限制。 C Result Cache 对参数组合不重复的查询收益最大。 D Result Cache 不涉及内存。
# 24. 物化视图在 OLAP 中的应用，预聚合如何加速报表查询，增量刷新与全量刷新的代价，与列存/实时数仓的互补关系？ A 物化视图每次都实时聚合明细。 B 物化视图总是全量刷新且无代价。 C 物化视图与列存、实时数仓完全冲突。 D 物化视图预聚合结果，报表直达，增量刷新代价低于全量刷新。 ✓ 正确答案
# 25. 物化视图的刷新策略（在执行计划与 SQL 优化范畴内）？ A 全量刷新重算全部数据，CONCURRENTLY 可并发但需唯一索引。 ✓ 正确答案 B 增量刷新代价高于全量刷新。 C 物化视图刷新总是阻塞查询。 D 物化视图无法增量刷新。
# 26. OR 条件改写为 UNION 的成本对比？ A OR 条件无法利用索引。 B OR 改写为 UNION 总是更快。 C OR 改写为 UNION 可让各分支分别走索引，但引入去重与合并代价。 ✓ 正确答案 D index merge 与 UNION 改写完全无关。
# 27. GroupAggregate 与 HashAggregate 的取舍，输入有序 vs 哈希？ A GroupAggregate 总是用哈希表。 B GroupAggregate 要求输入有序，HashAggregate 用哈希表且不要求有序。 ✓ 正确答案 C HashAggregate 要求输入有序。 D 两者实现完全相同。
# 28. Sort 节点的代价，内存排序 vs 外部归并排序（on-disk）？ A work_mem 不影响排序方式。 B 内存排序需要磁盘 I/O。 C 两种排序代价相同。 D 外部归并排序因磁盘 I/O 代价远高于内存排序。 ✓ 正确答案
# 29. 外部排序（External Sort）的磁盘 I/O 代价估算？ A 外部排序 I/O 近似数据量乘以（写入加归并轮数乘 2），归并轮数越多 I/O 越大。 ✓ 正确答案 B 外部排序 I/O 与数据量无关。 C 归并轮数不影响 I/O。 D 外部排序只在内存进行。
# 30. Hash Aggregate 的内存限制？ A work_mem 不影响 HashAggregate。 B HashAggregate 不受内存限制。 C HashAggregate 不使用哈希表。 D HashAggregate 的哈希表受 work_mem 限制，超限会落盘。 ✓ 正确答案
# 31. JIT（Just-In-Time）编译的原理，LLVM 编译表达式？ A JIT 只适合简单查询。 B JIT 只解释不编译。 C JIT 编译无任何开销。 D JIT 用 LLVM 把表达式、聚合等热路径编译为机器码，减少解释开销。 ✓ 正确答案
# 32. 并行查询（Parallel Query）的原理，leader worker + 多 worker 协同？ A 并行查询不需要 worker 进程。 B 并行查询只有一个 worker。 C Gather 节点下方是串行执行。 D 并行查询中 leader 协调，Gather 节点汇总各 worker 的部分结果。 ✓ 正确答案
# 33. 并行查询的代价，worker 协调、内存使用？ A 并行查询没有任何额外代价。 B 并行查询引入 worker 协调与内存放大代价，数据量小时可能得不偿失。 ✓ 正确答案 C 并行度越高查询一定越快。 D 并行不占用额外内存。
# 34. 采样的频率与代价，ANALYZE 的样本大小？ A 采样越大 ANALYZE 越快。 B ANALYZE 采样大小与频率共同决定统计准确性，需权衡精度与代价。 ✓ 正确答案 C 统计频率不影响估算精度。 D ANALYZE 不采样数据。
# 35. EXISTS 与 IN 的执行计划？ A EXISTS 永远比 IN 计划好。 B 现代优化器可将 EXISTS 与 IN 都转为半连接，计划往往相似。 ✓ 正确答案 C IN 无法转为半连接。 D 两者总是退化为逐行执行。
# 36. MySQL Query Cache（已废弃）的历史与教训？ A Query Cache 的失效与表更新无关。 B Query Cache 在写多读少场景性能极佳。 C Query Cache 只在 MySQL 8.0 存在。 D Query Cache 因表更新导致整体缓存失效并引入锁竞争，在写多场景反而降低性能而被废弃。 ✓ 正确答案
