“查询计划”(Query Plan,也叫执行计划)是数据库(或大数据引擎)在执行一条 SQL/查询语句前,生成的一种**“如何一步步取数据、怎么算、按什么顺序做”的方案**。
下面用通用原理 + 简化的生成流程来说明,不限定某一种数据库。
SQL 是**“声明式语言”**:
你只告诉数据库“我要什么结果”,而不是“怎么算”。
例如:
SELECT *
FROM orders
WHERE user_id = 10
AND order_date > '2024-01-01';
数据库需要决定:
user_id 还是 order_date?查询计划就是决策结果。
一般分 4 个阶段:
目标:把 SQL 文本变成结构化的语法树
过程:
示例结构(概念化):
SELECT
├─ columns: *
├─ FROM: orders
└─ WHERE
├─ user_id = 10
└─ order_date > '2024-01-01'
✅ 这一阶段不关心数据在哪、怎么算
目标:生成“语义等价但更高效”的逻辑执行方案
数据库会做很多“数学级别”的改写,例如:
谓词下推(Predicate Pushdown)
SELECT *
FROM (SELECT * FROM orders)
WHERE user_id = 10
→ 把 WHERE 提前到子查询里
投影下推
子查询展开 / 视图展开
连接顺序重排(逻辑层面)
去除无效条件
✅ 结果:逻辑查询计划(Logical Plan)
它描述:
这是查询计划生成的核心环节
数据库会估算:
公式(概念化):
Cost = I/O 成本 + CPU 成本 + 网络 / 内存开销
数据库会生成 多个候选物理计划,选一个“看起来最便宜的”。
得到一个树状结构,例如(简化):
Index Scan (user_id_index)
└── Filter (order_date > '2024-01-01')
执行时:
以 MySQL / PostgreSQL / Oracle 为例,常见算子包括:
| 算子 | 含义 |
|---|---|
| Seq Scan | 全表扫描 |
| Index Scan | 索引扫描 |
| Filter | 条件过滤 |
| Join | 表连接 |
| Sort | 排序 |
| Aggregate | 聚合 |
| Hash | 哈希表 |
| Nested Loop | 嵌套循环 |
示例(概念):
Nested Loop
├─ Index Scan on users (user_id = 10)
└─ Index Scan on orders (order_date > ...)
统计信息不准 → 选错计划 → 慢查询
SELECT * vs 指定列查询计划是数据库通过“解析 → 逻辑优化 → 基于代价的物理优化”生成的,用来决定“如何最高效地执行一条 SQL”的执行方案。
如果你愿意,我可以:
你可以直接把 SQL 或数据库类型发给我。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。