MySQL_执行计划
MySQL 执行计划
核心目的与实现
- 核心目标：提高查询效率
- 实现路径：通过
EXPLAIN关键字查看 SQL 的执行计划，重点检查索引是否生效 - 索引失效分析：如果索引未生效，通常归结为两类原因
- 代码原因：SQL 写法不规范（如对字段进行函数运算、隐式类型转换、违反最左前缀原则等）
- 系统原因：查询优化器认为全表扫描比走索引更快（例如数据量太小，或查询结果占比过高）
EXPLAIN
在 SQL 语句前加上
EXPLAIN，即可模拟优化器执行 SQL 的过程，并返回详细的信息结果集
结果集分析
1. id：执行顺序的指挥官
id 决定了表中操作的执行顺序，可以理解为“栈内队列”或执行优先级
- id 相同：执行顺序从上到下
- id 不同：id 值越大，优先级越高，越先执行（通常出现在子查询中）
- id 为 NULL：通常表示这是一个结果集，不需要进一步操作（如
UNION RESULT）
2. select_type：查询的类型
定义了 SELECT 语句的复杂程度
- PRIMARY：包含子查询部分，表示这是最外层的查询
- SUBQUERY：包含子查询，表示这是
SELECT或WHERE列表中的子查询 - UNION：被
UNION连接的部分，表示这是UNION后的第二个或后续的SELECT语句 - SIMPLE：简单查询，不包含子查询或
UNION
3. type：连接类型
重点关注指标
| 类型 | 描述 | 优化建议 |
|---|---|---|
| system | 表中只有一行记录（系统表） 是 const 的特例 |
无需优化 极少见 |
| const | 通过主键或唯一索引定位到一行数据 | 性能极快 如 WHERE id = 1 |
| eq_ref | 在连接查询中 使用了主键或唯一索引进行等值匹配 |
性能很好 通常出现在多表连接 |
| ref | 使用非唯一索引进行等值匹配 可能找到多行 |
性能较好 是常见的索引使用情况 |
| range | 使用索引进行范围查询 （如 BETWEEN, >, IN） |
性能尚可 优于全表扫描 |
| index | 全索引扫描 遍历整个索引树 |
比全表扫描快 但仍需优化 |
| ALL | 全表扫描 | 必须优化 通常意味着未命中索引 |