1
SELECT name, age FROM users WHERE age > 18;

1
如果 SQL 存在语法错误（比如 `SELEC name FORM users`），解析器会在这一步就报错，后续阶段不会执行。
2

3
### 2.2 语义分析
4

5
语法树只验证了 SQL 的"语法正确性"，但不知道 `users` 表是否存在、`name` 列是什么类型、当前用户有没有查询权限。语义分析负责这些检查：
6

7
- **名称解析**：将 SQL 中的表名、列名绑定到数据库元数据中的实际对象
8
- **类型检查**：验证表达式类型是否兼容（如不能把字符串和整数相加）
9
- **权限验证**：检查当前用户是否拥有对相关对象的访问权限
10

11
语义分析完成后，语法树被转换为**查询树（Query Tree）**，其中每个节点都绑定到了具体的数据库对象。
12

13
### 2.3 查询重写
14

15
查询重写阶段对查询树进行等价变换，使其更利于后续优化。常见的重写规则包括：
16

17
**视图展开**：将视图引用替换为视图定义的子查询。例如：
18

19
```sql
20
-- 假设 active_users 视图定义为：
21
-- SELECT * FROM users WHERE status = 'active'
22

23
-- 原始查询
24
SELECT name FROM active_users WHERE age > 18;
25

26
-- 重写后
27
SELECT name FROM users WHERE status = 'active' AND age > 18;
28
```text
29

30
**子查询提升**：将相关子查询改写为 Semi Join，避免逐行执行子查询：
31

32
```sql
33
-- 原始：相关子查询（每行都执行一次子查询）
34
SELECT * FROM orders o
35
WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.city = '北京');
36

37
-- 重写后：Semi Join（一次扫描完成）
38
SELECT o.* FROM orders o
39
SEMI JOIN users u ON u.id = o.user_id AND u.city = '北京';
40
```text
41

42
**常量折叠与表达式简化**：
43

44
```sql
45
-- 原始
46
SELECT * FROM users WHERE age > 10 + 8 AND 1 = 1;
47

48
-- 重写后
49
SELECT * FROM users WHERE age > 18;
50
```text
51

52
PostgreSQL 的规则系统（Rule System）也在此阶段工作——用户定义的 RULE 可以在重写阶段修改查询树，实现行级安全策略等高级功能。
53

54
## 三、查询优化
55

56
查询优化是整条流水线的核心。优化器的目标是在有限时间内找到代价最低的执行计划。优化分为两个层次：**逻辑优化**（基于规则）和**物理优化**（基于代价）。
57

58
### 3.1 逻辑优化（规则优化 / 启发式优化）
59

60
逻辑优化基于启发式规则（Heuristic Rules），对查询树进行等价变换，无需了解数据分布。这些规则通常能"无脑"减少中间结果集的大小：
61

62
**谓词下推（Predicate Pushdown）**：将过滤条件尽早执行，减少上游的数据量。
63

64
```sql
65
-- 优化前：先 Join 再过滤（中间结果大）
66
SELECT o.* FROM orders o JOIN users u ON o.user_id = u.id
67
WHERE u.city = '北京';
68

69
-- 优化后：先过滤再 Join（中间结果小）
70
SELECT o.* FROM orders o JOIN (SELECT * FROM users WHERE city = '北京') u
71
ON o.user_id = u.id;
72
```text
73

74
**列裁剪（Column Pruning）**：只读取查询需要的列，减少 I/O 和内存占用。在[索引原理](./03-索引原理.md)中讨论的覆盖索引，正是列裁剪在索引层面的体现。
75

76
**Join 重排序**：调整 Join 的顺序，将小表或过滤后行数少的表放在前面。这是优化器搜索空间最大的来源——N 张表的 Join 有 N! 种排列顺序。
77

78
### 3.2 物理优化（代价优化）
79

80
逻辑优化决定了"做什么"，物理优化决定"怎么做"。同一个逻辑算子有多种物理实现，代价各不相同：
81

82
```mermaid
83
flowchart TD
84
    subgraph 逻辑算子["逻辑算子"]
85
        SCAN["TableScan"]
86
        FILTER["Filter"]
87
        JOIN["Join"]
88
        SORT["Sort"]
89
        AGG["Aggregate"]
90
    end
91

92
    subgraph 物理实现["物理实现选择"]
93
        SEQ["顺序扫描<br/>Seq Scan"]
94
        IDX["索引扫描<br/>Index Scan"]
95
        IDXONLY["索引只读扫描<br/>Index Only Scan"]
96
        NL["Nested Loop Join"]
97
        HJ["Hash Join"]
98
        SMJ["Sort Merge Join"]
99
        INMEM["内存排序"]
100
        EXTSORT["外部排序"]
101
        HASHAGG["Hash Aggregate"]
102
        SORTAGG["Sort Aggregate"]
103
    end
104

105
    SCAN --> SEQ
106
    SCAN --> IDX
107
    SCAN --> IDXONLY
108
    JOIN --> NL
109
    JOIN --> HJ
110
    JOIN --> SMJ
111
    SORT --> INMEM
112
    SORT --> EXTSORT
113
    AGG --> HASHAGG
114
    AGG --> SORTAGG
115

116
    style 逻辑算子 fill:#e8f5e9,stroke:#2e7d32
117
    style 物理实现 fill:#fff3e0,stroke:#e65100
118
```text
119

120
### 3.3 Join 算法选择
121

122
Join 是最复杂也最关键的算子。四种经典 Join 算法各有适用场景：
123

124
```mermaid
125
flowchart TD
126
    START["Join 操作"] --> SIZE{"两表大小关系？"}
127

128
    SIZE -->|"一表很小<br/>（可放内存）"| NL["Nested Loop Join<br/>小表做外表<br/>O(M×N)"]
129
    SIZE -->|"两表都大<br/>无序"| HJ["Hash Join<br/>小表建 Hash 表<br/>O(M+N)"]
130
    SIZE -->|"两表都大<br/>已排序"| SMJ["Sort Merge Join<br/>双指针扫描<br/>O(M+N)"]
131
    SIZE -->|"两表都大<br/>内存不足"| GHJ["Grace Hash Join<br/>分区+逐区 Hash Join<br/>O(M+N) I/O"]
132

133
    NL --> NL_NOTE["适合：有索引可用<br/>或小表驱动大表"]
134
    HJ --> HJ_NOTE["适合：等值 Join<br/>无排序要求"]
135
    SMJ --> SMJ_NOTE["适合：非等值 Join<br/>或数据已有序"]
136
    GHJ --> GHJ_NOTE["适合：等值 Join<br/>内存不足场景"]
137

138
    style START fill:#e3f2fd,stroke:#1565c0
139
    style NL fill:#e8f5e9,stroke:#2e7d32
140
    style HJ fill:#fff3e0,stroke:#e65100
141
    style SMJ fill:#fce4ec,stroke:#c62828
142
    style GHJ fill:#f3e5f5,stroke:#6a1b9a
143
```text
144

145
| Join 算法 | 时间复杂度 | 适用场景 | 优势 | 劣势 |
146
|-----------|-----------|---------|------|------|
147
| Nested Loop | O(M×N) | 小表驱动大表、有索引 | 简单、支持非等值 Join | 大表全扫描极慢 |
148
| Hash Join | O(M+N) | 等值 Join、两表都大 | 等值 Join 最快 | 只支持等值、需内存 |
149
| Sort Merge | O(MlogM+NlogN) | 数据已排序、非等值 | 支持非等值、可利用索引序 | 需要排序开销 |
150
| Grace Hash | O(M+N) I/O | 等值 Join、内存不足 | 突破内存限制 | 多轮 I/O |
151

152
> [!TIP]
153
> MySQL 8.0 之前只支持 Nested Loop Join（含 Block Nested Loop 变体），8.0 引入了 Hash Join，大幅提升了无索引等值 Join 的性能。PostgreSQL 则长期支持全部四种算法。更多实现细节参见 [MySQL 深入](./06-MySQL深入.md) 和 [PostgreSQL 深入](./07-PostgreSQL深入.md)。
154

155
## 四、代价模型
156

157
优化器如何从众多候选计划中选出"最优"？答案是**代价模型（Cost Model）**——为每个候选计划估算一个代价分数，选择代价最低的。
158

159
### 4.1 代价的三个维度
160

161
代价模型通常考虑三个维度：
162

163
| 维度 | 含义 | 典型权重 |
164
|------|------|----------|
165
| **I/O 代价** | 读写磁盘页面的次数 | 最高（磁盘比内存慢 10^5 倍） |
166
| **CPU 代价** | 计算表达式、比较元组的开销 | 中等 |
167
| **网络代价** | 分布式查询的数据传输量 | 分布式场景下最高 |
168

169
总代价 = seq_page_cost × I/O 页数 + cpu_tuple_cost × 元组数 + cpu_index_cost × 索引扫描次数 + ...
170

171
### 4.2 PostgreSQL 代价估算
172

173
PostgreSQL 的代价模型是最透明的。以下是一个 Seq Scan 的代价估算公式：

1
Index Scan 的代价估算更复杂，需要考虑 B+ 树的高度、叶子页的随机 I/O、以及选择率：

1
> [!WARNING]
2
> `random_page_cost` 默认值为 4.0，这是基于传统机械硬盘的假设。在 SSD 上，随机 I/O 和顺序 I/O 的差距远没有 4 倍。生产环境使用 SSD 时，建议将 `random_page_cost` 设为 1.1~1.5，否则优化器会过度偏好顺序扫描。
3

4
### 4.3 MySQL 代价估算
5

6
MySQL 的代价模型在 8.0 版本经历了重大重构，从硬编码改为可配置的代价常量：
7

8
```sql
9
-- 查看 MySQL 代价常量
10
SELECT * FROM mysql.server_cost;
11
SELECT * FROM mysql.engine_cost;
12
```text

1
### 4.4 统计信息：代价估算的基石
2

3
代价估算的准确性完全依赖于**统计信息**。没有准确的统计信息，再精妙的代价模型也是空中楼阁。
4

5
核心统计指标：
6

7
| 统计指标 | 含义 | 用途 |
8
|---------|------|------|
9
| **NDV**（Number of Distinct Values） | 列的唯一值数量 | 估算等值条件的选择率 = 1/NDV |
10
| **直方图**（Histogram） | 列值分布的频率统计 | 估算范围条件的选择率 |
11
| **MCV**（Most Common Values） | 高频值及其频率 | 估算偏斜分布的选择率 |
12
| **相关性**（Correlation） | 列值物理排序与逻辑排序的相关度 | 决定 Index Scan 的额外随机 I/O |
13

14
选择率（Selectivity）是代价估算的核心概念——它决定了过滤后剩余多少行：
15

16
```python
17
# 选择率估算示例（简化版）
18
def estimate_selectivity(column, predicate, stats):
19
    if predicate.type == "equality":
20
        # 等值条件：1/NDV（均匀分布假设）
21
        return 1.0 / stats.ndv[column]
22
    elif predicate.type == "range":
23
        # 范围条件：用直方图估算
24
        return stats.histogram[column].fraction_in_range(
25
            predicate.lower, predicate.upper
26
        )
27
    elif predicate.type == "in_list":
28
        # IN 列表：每个值的频率之和
29
        return sum(stats.mcv[column].get(v, 1.0/stats.ndv[column])
30
                   for v in predicate.values)
31
```text
32

33
> [!NOTE]
34
> 统计信息失真是执行计划劣化的头号原因。一张百万行的表，如果统计信息显示只有 1000 行，优化器可能选择 Index Scan；但实际扫描百万行的 Index Scan 比 Seq Scan 慢得多——因为随机 I/O 的代价远高于顺序 I/O。这就是为什么定期收集统计信息至关重要。
35

36
## 五、执行引擎
37

38
优化器生成执行计划后，执行引擎负责按计划执行。执行引擎的架构模型决定了查询的执行方式，对性能影响深远。
39

40
### 5.1 三种执行模型
41

42
```mermaid
43
flowchart TB
44
    subgraph Volcano["Volcano/Iterator 模型（拉模型）"]
45
        direction TB
46
        V_OUT["Result"] -->|"next()"| V_JOIN["Hash Join"]
47
        V_JOIN -->|"next()"| V_SCAN1["Scan: users"]
48
        V_JOIN -->|"build()"| V_SCAN2["Scan: orders"]
49
    end
50

51
    subgraph Vectorized["向量化模型（批处理）"]
52
        direction TB
53
        VZ_OUT["Result"] -->|"next_batch()"| VZ_JOIN["Hash Join"]
54
        VZ_JOIN -->|"next_batch()"| VZ_SCAN1["Scan: users"]
55
        VZ_JOIN -->|"build()"| VZ_SCAN2["Scan: orders"]
56
    end
57

58
    subgraph Compiled["编译执行模型（推模型）"]
59
        direction TB
60
        C_CODE["编译生成的代码"] --> C_LOOP["for row in users:"]
61
        C_LOOP --> C_HASH["hash_table.insert(row)"]
62
        C_HASH --> C_LOOP2["for row in orders:"]
63
        C_LOOP2 --> C_PROBE["hash_table.probe(row)"]
64
        C_PROBE --> C_EMIT["emit(row)"]
65
    end
66

67
    style Volcano fill:#e3f2fd,stroke:#1565c0
68
    style Vectorized fill:#e8f5e9,stroke:#2e7d32
69
    style Compiled fill:#fff3e0,stroke:#e65100
70
```text
71

72
| 模型 | 执行方式 | 虚函数调用 | CPU 缓存 | 适用场景 |
73
|------|---------|-----------|---------|---------|
74
| **Volcano/Iterator** | 每次拉取一行 | 每行 N 次 | 差（逐行跳转） | 通用、易实现 |
75
| **Vectorized** | 每次拉取一批（如 1024 行） | 每批 N 次 | 好（批处理） | OLAP 分析查询 |
76
| **Compiled** | 编译为机器码 | 无虚函数调用 | 最好（紧凑循环） | 重复执行的查询 |
77

78
### 5.2 Volcano 模型详解
79

80
Volcano 模型（又称 Iterator 模型）是最经典的执行模型，几乎所有数据库都支持。每个算子实现三个接口：
81

82
- `open()`：初始化（如 Hash Join 建立哈希表）
83
- `next()`：返回下一行，没有更多行时返回 null
84
- `close()`：释放资源
85

86
```python
87
# Volcano 模型的 Hash Join 伪代码
88
class HashJoin(Operator):
89
    def open(self):
90
        self.hash_table = {}
91
        self.build_child.open()
92
        while (row := self.build_child.next()) is not None:
93
            self.hash_table[self.key(row)] = row
94
        self.build_child.close()
95
        self.probe_child.open()
96

97
    def next(self):
98
        while (row := self.probe_child.next()) is not None:
99
            if self.key(row) in self.hash_table:
100
                return self.emit(self.hash_table[self.key(row)], row)
101
        return None
102
```text
103

104
Volcano 模型的优势是**简洁和通用**——任何算子只需实现 `open/next/close`，即可自由组合。劣势是**虚函数调用开销**——每行数据都要经过多次虚函数调用，对 CPU 流水线不友好。
105

106
### 5.3 向量化执行
107

108
向量化执行（Vectorized Execution）是对 Volcano 模型的改进：每次 `next()` 返回一批行（通常 1024 行），而不是一行。这大幅减少了虚函数调用次数，并且批处理模式让 CPU 的 SIMD 指令和缓存预取得以发挥作用。
109

110
DuckDB、ClickHouse 等分析型数据库广泛采用向量化执行。在 OLAP 场景下，向量化比 Volcano 快 5-10 倍并不罕见。
111

112
### 5.4 编译执行
113

114
编译执行（Compiled Execution）将整个查询计划编译成一段机器码，消除了所有虚函数调用。Hyper 系统率先提出这一思路，后来被 Apache Spark 的 Whole-Stage Code Generation 和 SQL Server 采用。
115

116
编译执行在查询重复执行时性能最优，但编译本身有开销，对于只执行一次的查询（如 ad-hoc 查询）可能得不偿失。
117

118
## 六、EXPLAIN 解读
119

120
理解了查询处理的全流程，现在学会读懂 EXPLAIN——这是你与优化器对话的窗口。
121

122
### 6.1 MySQL EXPLAIN 字段详解
123

124
```sql
125
EXPLAIN SELECT u.name, COUNT(*) AS order_count
126
FROM users u
127
JOIN orders o ON u.id = o.user_id
128
WHERE u.city = '北京' AND o.status = 'completed'
129
GROUP BY u.name;
130
```text

1
关键字段解读：
2

3
| 字段 | 含义 | 关注点 |
4
|------|------|--------|
5
| **type** | 访问类型 | 从好到差：system > const > eq_ref > ref > range > index > ALL |
6
| **key** | 实际使用的索引 | NULL 表示未使用索引（全表扫描） |
7
| **rows** | 预估扫描行数 | 越小越好，依赖统计信息 |
8
| **filtered** | 过滤比例 | 100% 最好，10% 表示 90% 的行被丢弃 |
9
| **Extra** | 额外信息 | Using filesort/Using temporary 是危险信号 |
10

11
### 6.2 PostgreSQL EXPLAIN ANALYZE
12

13
PostgreSQL 的 EXPLAIN ANALYZE 不仅显示预估代价，还显示实际执行时间，是诊断计划偏差的利器：
14

15
```sql
16
EXPLAIN ANALYZE
17
SELECT u.name, COUNT(*) AS order_count
18
FROM users u
19
JOIN orders o ON u.id = o.user_id
20
WHERE u.city = '北京' AND o.status = 'completed'
21
GROUP BY u.name;
22
```text

1
> [!IMPORTANT]
2
> 注意 `cost`（预估）和 `actual`（实际）的对比。如果两者差距很大，说明统计信息失真——这是执行计划劣化的最常见原因。上例中预估 5000 行、实际 4800 行，偏差在可接受范围内。
3

4
### 6.3 跨数据库 EXPLAIN 对比
5

6
| 特性 | MySQL | PostgreSQL |
7
|------|-------|------------|
8
| 基本命令 | `EXPLAIN SQL` | `EXPLAIN SQL` |
9
| 实际执行 | `EXPLAIN ANALYZE`（8.0.18+） | `EXPLAIN ANALYZE` |
10
| 输出格式 | 表格 / JSON / Tree | 文本 / JSON / YAML |
11
| 预估代价 | 不显示 | 显示（cost=...） |
12
| 实际行数 | 8.0.18+ 支持 | 一直支持 |
13
| 执行时间 | 8.0.18+ 支持 | 一直支持 |
14
| Buffer 统计 | 不支持 | `BUFFERS` 选项 |
15
| WAL 统计 | 不支持 | `WAL` 选项 |
16

17
### 6.4 实战案例：从慢到优
18

19
**案例 1：隐式类型转换导致索引失效**
20

21
```sql
22
-- 慢：phone 是 VARCHAR，传入整数导致隐式转换，索引失效
23
EXPLAIN SELECT * FROM users WHERE phone = 13800138000;
24
-- type: ALL, rows: 1000000, Extra: Using where
25

26
-- 快：传入字符串，走索引
27
EXPLAIN SELECT * FROM users WHERE phone = '13800138000';
28
-- type: ref, key: idx_phone, rows: 1
29
```text
30

31
**案例 2：最左前缀原则违反**
32

33
```sql
34
-- 慢：联合索引 (city, age, name)，跳过 city 直接查 age
35
EXPLAIN SELECT * FROM users WHERE age > 18;
36
-- type: ALL, rows: 1000000
37

38
-- 快：遵循最左前缀
39
EXPLAIN SELECT * FROM users WHERE city = '北京' AND age > 18;
40
-- type: range, key: idx_city_age_name, rows: 5000
41
```text
42

43
**案例 3：ORDER BY 导致 filesort**
44

45
```sql
46
-- 慢：索引在 (status)，但 ORDER BY created_at 无索引
47
EXPLAIN SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at LIMIT 10;
48
-- Extra: Using where; Using filesort
49

50
-- 快：建立覆盖排序的联合索引
51
CREATE INDEX idx_status_created ON orders(status, created_at);
52
EXPLAIN SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at LIMIT 10;
53
-- type: ref, key: idx_status_created, Extra: Using index condition
54
```text
55

56
**案例 4：小表驱动大表**
57

58
```sql
59
-- 慢：大表做外表，扫描 100 万行
60
EXPLAIN SELECT * FROM large_table l JOIN small_table s ON l.key = s.key;
61
-- Nested Loop, 驱动表 large_table
62

63
-- 快：小表做外表，只扫描 1000 行
64
EXPLAIN SELECT /*+ QB_NAME(main) */ * FROM small_table s
65
JOIN large_table l ON l.key = s.key;
66
-- Hash Join, build 侧 small_table
67
```text
68

69
## 七、统计信息与绑定
70

71
### 7.1 统计信息收集
72

73
统计信息不会自动保持最新——大量 INSERT/UPDATE/DELETE 后，统计信息会逐渐失真。必须定期收集：
74

75
```sql
76
-- PostgreSQL：手动收集统计信息
77
ANALYZE users;                    -- 只收集 users 表
78
ANALYZE users(name, city);        -- 只收集指定列
79
VACUUM ANALYZE;                   -- 同时回收空间和收集统计信息
80

81
-- 设置自动收集的阈值
82
ALTER TABLE users SET (autovacuum_analyze_threshold = 100);
83
ALTER TABLE users SET (autovacuum_analyze_scale_factor = 0.05);
84
```text
85

86
```sql
87
-- MySQL：手动收集统计信息
88
ANALYZE TABLE users;
89

90
-- 查看统计信息
91
SHOW INDEX FROM users;            -- 查看索引的 Cardinality
92
SELECT * FROM information_schema.STATISTICS
93
WHERE TABLE_NAME = 'users';
94
```text
95

96
PostgreSQL 还支持扩展统计信息，用于捕获多列相关性：
97

98
```sql
99
-- 创建多列统计信息（捕获 city 和 age 的相关性）
100
CREATE STATISTICS s1 (ndistinct, dependencies, mcv) ON city, age FROM users;
101
ANALYZE users;
102

103
-- 查看统计信息
104
SELECT * FROM pg_stats WHERE tablename = 'users';
105
```text
106

107
### 7.2 计划缓存与参数化
108

109
数据库会缓存执行计划，避免重复优化。但参数化查询的计划缓存有一个经典陷阱——**参数嗅探（Parameter Sniffing）**：
110

111
```sql
112
-- 第一次执行：city = '北京' 返回 50 万行，优化器选择 Seq Scan
113
PREPARE get_users(VARCHAR) AS SELECT * FROM users WHERE city = $1;
114
EXECUTE get_users('北京');
115

116
-- 第二次执行：city = '拉萨' 返回 100 行，但复用了 Seq Scan 的计划！
117
EXECUTE get_users('拉萨');
118
```text
119

120
PostgreSQL 使用**通用计划（Generic Plan）**和**自定义计划（Custom Plan）**的自动切换来缓解此问题。MySQL 8.0 则引入了 `optimizer_switch` 中的条件来控制计划缓存行为。
121

122
### 7.3 Plan Hint
123

124
当优化器选错计划时，可以通过 Hint 强制指定执行路径：
125

126
```sql
127
-- MySQL：USE INDEX / FORCE INDEX
128
SELECT * FROM users USE INDEX(idx_city) WHERE city = '北京';
129
SELECT * FROM users FORCE INDEX(idx_city) WHERE city = '北京';
130

131
-- USE INDEX：建议使用，优化器仍可忽略
132
-- FORCE INDEX：强制使用，除非无法使用（如索引不包含所需列）
133
```text
134

135
```sql
136
-- PostgreSQL：通过 pg_hint_plan 扩展
137
/*+ SeqScan(users) HashJoin(users orders) */
138
SELECT u.name, COUNT(*)
139
FROM users u JOIN orders o ON u.id = o.user_id
140
WHERE u.city = '北京' GROUP BY u.name;
141
```text
142

143
### 7.4 绑定执行计划
144

145
比 Hint 更可靠的方式是**绑定执行计划**——将特定 SQL 模式与固定的执行计划关联：
146

147
| 数据库 | 机制 | 说明 |
148
|--------|------|------|
149
| **MySQL** | SQL Profile | 记录查询的资源消耗，辅助优化器决策 |
150
| **MySQL** | Optimizer Hint | `SET_VAR(optimizer_switch='...')` |
151
| **PostgreSQL** | Plan Guide（pg_plan_filter） | 第三方扩展，限制计划选择 |
152
| **SQL Server** | Plan Guide | 原生支持，最成熟的计划绑定机制 |
153
| **Oracle** | SQL Profile / Baseline | 自动捕获 + 手动固定 |
154

155
> [!TIP]
156
> 绑定执行计划是"双刃剑"——它绕过了优化器，数据分布变化后可能适得其反。只在确认优化器反复选错计划时才使用，并定期审查绑定的计划是否仍然最优。更多调优策略参见 [性能优化](./09-数据库性能优化.md)。
157

158
## ·附、实践：PostgreSQL EXPLAIN 解读
159

160
> 本节用 PostgreSQL 的 EXPLAIN ANALYZE 观察查询执行计划。需要 PostgreSQL 环境。
161

162
### 1. 创建测试数据
163

164
```sql
165
CREATE TABLE orders (
166
    id SERIAL PRIMARY KEY,
167
    user_id INTEGER,
168
    amount NUMERIC,
169
    status TEXT,
170
    created_at TIMESTAMP DEFAULT NOW()
171
);
172

173
-- 插入 1000 行测试数据
174
INSERT INTO orders (user_id, amount, status)
175
SELECT
176
    (random() * 100)::int,
177
    (random() * 1000)::numeric(10,2),
178
    CASE WHEN random() < 0.3 THEN 'pending'
179
         WHEN random() < 0.7 THEN 'shipped'
180
         ELSE 'delivered' END
181
FROM generate_series(1, 1000);
182

183
CREATE INDEX idx_orders_user_id ON orders(user_id);
184
```text
185

186
### 2. 索引扫描 vs 全表扫描
187

188
```sql
189
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;
190
```text
191

192
```text
193
                                                       QUERY PLAN
194
-------------------------------------------------------------------------------------------------------------------------
195
 Bitmap Heap Scan on orders  (cost=4.33..12.56 rows=7 width=30) (actual time=0.126..0.159 rows=7 loops=1)
196
   Recheck Cond: (user_id = 42)
197
   Heap Blocks: exact=5
198
   ->  Bitmap Index Scan on idx_orders_user_id  (cost=0.00..4.33 rows=7 width=0) (actual time=0.075..0.075 rows=7 loops=1)
199
         Index Cond: (user_id = 42)
200
 Planning Time: 1.552 ms
201
 Execution Time: 0.346 ms
202
```text
203

204
**解读**：
205
- `Bitmap Index Scan`：先在索引中找到所有满足条件的行，收集为位图
206
- `Bitmap Heap Scan`：根据位图回表读取数据页（`Heap Blocks: exact=5` 表示访问了 5 个数据页）
207
- `actual time=0.126..0.159`：启动时间 0.126ms，总时间 0.159ms
208
- `rows=7`：实际返回 7 行
209

210
### 3. 聚合查询的执行计划
211

212
```sql
213
EXPLAIN ANALYZE SELECT status, COUNT(*), AVG(amount) FROM orders GROUP BY status;
214
```text
215

216
```text
217
                                                  QUERY PLAN
218
--------------------------------------------------------------------------------------------------------------
219
 HashAggregate  (cost=25.50..25.54 rows=3 width=48) (actual time=0.271..0.273 rows=3 loops=1)
220
   Group Key: status
221
   Batches: 1  Memory Usage: 24kB
222
   ->  Seq Scan on orders  (cost=0.00..18.00 rows=1000 width=14) (actual time=0.004..0.096 rows=1000 loops=1)
223
 Planning Time: 1.123 ms
224
 Execution Time: 0.437 ms