SQL执行计划中type字段表示单表数据访问方式，反映扫描效率而非连接算法；从优到劣依次为system、const、eq_ref、ref、fulltext、ref_or_null、index_merge、range、index、ALL，需结合key、rows、Extra综合判断性能。
SQL执行计划中的type字段（也称access type或join type）表示MySQL如何定位和访问表中的数据行，直接反映该表的扫描方式与效率。它不是指表之间的连接算法（如Nested Loop、Hash Join），而是单表访问路径的级别，是判断SQL是否走索引、是否全表扫描的关键指标。
type值从优到劣的常见顺序及含义
MySQL官方文档定义了type的多个取值，按性能由高到低大致如下（实际需结合key、rows、Extra综合判断）：
- system：表只有一行（常为系统表），最快，几乎无成本
-
const：通过主键或唯一索引等值查询，且匹配结果最多一行（如
WHERE id = 1）。优化器可将该表转为常量 -
eq_ref：多表连接中，使用主键或唯一索引进行等值关联（如
t1.id = t2.t1_id，且t2.t1_id有唯一索引）。每行t1最多匹配t2的一行 -
ref：非唯一索引等值查询（如
WHERE status = 'active'，status有普通索引）。可能返回多行，但能利用索引快速定位 -
fulltext：全文索引检索，专用于
MATCH ... AGAINST -
ref_or_null：类似
ref，但额外包含IS NULL条件（如WHERE col = ? OR col IS NULL） -
index_merge：使用多个索引分别扫描后合并结果（
EXPLAIN中key显示多个索引名）。说明单个索引不够优，但优化器尝试组合弥补 -
unique_subquery / index_subquery：出现在
IN子查询中，分别对应唯一索引和普通索引驱动的子查询 -
range：索引范围扫描（如
WHERE id BETWEEN 10 AND 20、WHERE created_at > '2023-01-01'）。比全表扫描快，但不如等值高效 - index：全索引扫描（即遍历整个索引B+树叶子节点）。虽不读数据页，但若索引宽或行数多，开销仍大
- ALL：全表扫描，最差情况。逐行读取聚簇索引（数据页），I/O和CPU消耗最高
哪些type值得警惕？典型成因与优化方向
当出现index或ALL，尤其在大表上，应重点排查；range若配合高rows值，也需关注。
-
ALL / index 常见原因：缺少合适索引、索引失效（如对索引列做函数/运算：
WHERE YEAR(create_time) = 2023）、隐式类型转换（varchar字段传入数字）、LIKE以通配符开头（LIKE '%abc'） -
range 效率不高时：范围过大（如
id > 0）、复合索引未满足最左前缀（INDEX(a,b,c)，却查WHERE b = 1）、统计信息过期导致优化器误判 -
ref_or_null 或 index_merge 频繁出现：暗示当前索引设计不能覆盖查询需求，建议合并索引或重构查询逻辑（如拆分
OR条件）
结合key、rows、Extra看type才完整
type只是访问类型，必须联动其他字段才能准确评估性能：
-
key：显示实际使用的索引。若type是ref但key为NULL，说明索引未被用上 -
rows：优化器预估扫描行数。即使type=ref，若rows高达百万，仍可能慢 -
Extra：补充关键信息。如Using filesort、Using temporary、Using index condition等，直接影响执行代价
例如：type=range + key=idx_status + rows=50000 + Extra=Using index condition，说明用了索引下推，但范围太大，考虑加过滤条件或调整索引顺序。
实战检查建议
- 对慢查询，先
EXPLAIN FORMAT=TREE（8.0+）或EXPLAIN ANALYZE（8.0.18+）看真实执行耗时分布 - 确认
type是否为const/eq_ref/ref；避免ALL出现在核心大表 - 检查
key是否命中预期索引；若没命中，用SHOW INDEX FROM table核对索引定义 - 用
ANALYZE TABLE更新统计信息，防止优化器基于过期数据选错执行计划 - 对
range或index，用SELECT COUNT(*)验证实际扫描行数是否与rows接近
