访问类型分级
访问类型是执行计划里最直观的性能档位，它描述优化器打算怎么找到满足条件的行：从常量查找、唯一索引等值匹配、普通索引等值匹配、索引范围扫描，一路到全索引扫描与全表扫描。优化的目标就是把关键查询的档位推进到等值或范围这一档。但它不是唯一标准——小表全扫可能比走索引更快，判断时要结合扫描行数与表规模。
基本信息
| 用途 | 判断语句的访问方式与性能档位 |
|---|---|
| 从好到差 | 常量 → 唯一索引等值 → 普通索引等值 → 范围 → 全索引扫描 → 全表扫描 |
| 关键判断 | 是否走了索引，扫描行数处于什么量级 |
| 常见误区 | 把全索引扫描当成走了索引就没问题 |
| 观察方法 | 查看执行计划中对应的那一列 |
| 版本差异 | 主流版本取值一致 |
典型使用场景
- 慢查询优化第一步：先看档位，再决定补索引还是改写法
- 索引上线验收：确认档位从全表扫描提升到等值匹配
- 连表查询排查：被驱动表是否用了唯一索引匹配
- 范围查询评估：扫描范围是否可控
- 核心语句巡检：捕捉档位劣化
- 结构改造前评估：确认关键路径依赖哪个索引
查看用例
查看用例
EXPLAIN SELECT * FROM appdb.users WHERE email = 'a@b.com'; # 唯一索引等值，档位最好
EXPLAIN SELECT * FROM appdb.orders WHERE user_id = 1; # 普通索引等值匹配，日常目标档位
EXPLAIN SELECT * FROM appdb.orders WHERE created_at >= '2026-10-01'; # 索引范围扫描
EXPLAIN SELECT * FROM appdb.orders WHERE status = 1; # 条件列无索引时退化为全表扫描档位与判读
| 档位 | 含义 | 判读要点 |
|---|---|---|
| 常量查找 | 主键或唯一键等值命中单行 | 最快，无需优化 |
| 唯一索引匹配 | 连表时用唯一索引逐行对应 | 连表查询的理想档位 |
| 普通索引等值匹配 | 用普通索引定位一组行 | 日常追求的档位 |
| 索引范围扫描 | 按范围读取索引区间 | 可接受，注意范围大小 |
| 全索引扫描 | 遍历整个索引树 | 偏慢，接近全表扫描 |
| 全表扫描 | 逐行读取整张表 | 重点治理对象 |
| 候选索引为空 | 没有任何可用索引 | 先补索引再看档位 |
全表扫描不一定是错误：小表上全扫往往比走索引更便宜，判断要结合估算行数与表规模，而不是一看到全表扫描就动手改造。
全索引扫描容易被误当成走索引就没问题：它遍历整个索引树，性能接近全表扫描，只是读取对象从表变成了索引。
只看档位不看扫描行数会漏掉真正的瓶颈：档位看着正常但估算行数巨大时，代价依然很高，两者必须一起判断。
档位优化清单
- 先确认候选索引是否为空，为空就直接补索引
- 确认复合索引的前缀是否与条件匹配
- 确认条件列是否被函数或运算包住
- 确认扫描行数的量级是否可接受
- 小表全扫可以接受，不要为了档位强行加索引
- 优化后重新查看计划，确认档位确实提升
档位是优化器基于统计信息的选择结果：数据分布变化后同一条语句可能落到不同档位，因此关键语句的访问类型要定期复核，而不是上线时看一次就归档。