第6章 查询优化器

第6章 · 查询优化器

章节摘要：同一条 SQL 往往有成千上万种执行方式，优化器的工作是在毫秒级时间里选出最便宜的一种。本章拆解 SQLite 优化器的三段架构——查询重写、连接顺序搜索、计划生成；算清成本模型的账（页访问次数、估算行数、索引代价）；盘点子查询扁平化、条件下推、IN 化等关键优化技术的适用条件，并对照 MySQL 与 PostgreSQL 优化器的同与不同。读完本章，你能预判优化器的选择，也能解释它为什么偶尔选错。

学习目标

读完本章，你应当能够：

1. 描述 SQLite 优化器的处理流水：语义分析后的重写（子查询扁平化、谓词推进）到 N 元连接的顺序搜索再到字节码生成。
2. 解释连接顺序搜索的组合爆炸问题与 SQLite 的剪枝策略（N 较小时穷举、较大时贪心），并对照 PostgreSQL 的动态规划与遗传查询优化。
3. 用成本模型的语言解释计划选择：估算行数、页访问代价、临时排序的开销从哪里来。
4. 列出至少四种关键优化技术（扁平化、下推、IN 化、ORDER BY 消除）各自的触发条件。
5. 诊断"优化器选错计划"的三类原因：统计过期、偏斜分布、查询形态超出模型假设。

核心概念速览

一句金句：优化器不做优化，它做选择题——题库是你给的索引与统计，评分标准是成本模型；想让它选对，先保证题库真实。

子章节导航

6.1 优化器架构与连接顺序：重写阶段的四个动作；连接顺序为什么是 NP 难问题的工程化裁剪；三库的搜索策略对照，以及用 CROSS JOIN 钉死顺序的强制手段。

6.2 成本模型与计划选择：SQLite 的"页访问次数近似"、三库代价参数对照、估算行数的来源与失真场景，以及 ANALYZE 纪律如何维持尺子的准确。

6.3 关键优化技术：子查询扁平化、WHERE 下推、IN 化与索引利用、排序消除——每项的触发条件与失效场景，收束成一份查询改写五道闸自查清单。

子章节之间的逻辑关系

三节是"搜索空间 → 评分函数 → 常用套路"。6.1 说清优化器在哪些候选里挑（连接顺序的搜索树），6.2 说清它用什么尺子挑（成本模型），6.3 列出它内置的题眼套路（重写技术）——三者合一，你就具备了"反向工程优化器意图"的能力：看到计划能倒推它算的账，看到坏计划能定位是搜索漏了还是账算错了。

6.1 搜索策略 ──▶ 6.2 成本模型 ──▶ 6.3 重写技术
    在哪挑          怎么比            有哪些现成套路
                        │
                        ▼
        第7章：执行时的内存配置如何反哺计划质量
​

前置知识与后续延伸

前置：第 5 章的选择性与 EXPLAIN QUERY PLAN 读法——本章的成本讨论全部建立在那两个概念上；第 3 章的字节码视角帮助理解"计划即指令序列"。

后续延伸：第 7 章的页缓存大小影响"顺序读与随机读的真实差价"，从而影响最优计划；第 8 章的诊断工具箱里有验证计划假设的实操。读法建议：6.1 与 6.2 连读——搜索策略与评分函数是一对搭档，分开读容易把优化器想象成玄学；6.3 可以当作工具箱按需查阅。带着问题读：为什么 SQLite 不做"运行时反馈优化"，而 PostgreSQL 敢做通用计划与定制计划的切换？

一个贯穿本章的自查动作：把你业务里最慢的三条查询拿出来，跑 EXPLAIN QUERY PLAN，对照 6.3 节末尾的五道闸清单逐条检查。本章内容读完后，这三条查询至少应该有一条在你手里被改写出可量化的提速——这是检验本章吸收程度最直接的方式。