type值反映索引使用效率而非是否启用，性能梯队为const≈eq_ref>ref>range>index>all；index和all均属低效，优化重点在where写法避免函数、隐式转换、运算符及不满足最左前缀。
type列直接暴露查询是否走索引、走得多深——它不是“有没有索引”，而是“有没有高效用索引”。
看type值排序，先认准性能梯队
MySQL的type从好到坏有明确层级：const ≈ eq_ref > ref > range > index > ALL。别只盯着是不是NULL，index看着像走了索引，实际是遍历整棵B+树叶子节点，I/O开销常和ALL接近。
-
const：主键或唯一索引等值查，命中单行，最快 -
eq_ref：JOIN中用主键/唯一索引关联，每行只匹配一次 -
ref：非唯一索引等值匹配（如WHERE status = 'active'），可能返回多行 -
range：索引范围扫描（如WHERE created_at > '2025-01-01'），注意左前缀必须满足 -
index：全索引扫描，没WHERE也触发；或WHERE条件无法下推到引擎层时退化至此 -
ALL：全表扫描，优先检查WHERE里是否有函数、隐式转换、运算符干扰
遇到type=index或ALL，先查WHERE写法是否“索引不友好”
建了索引却没生效，90%出在SQL写法上。优化器会主动放弃索引，如果它估算走索引比全表还慢——而这个判断往往被你的写法误导。
-
WHERE YEAR(create_time) = 2025→ 函数导致索引失效，改用WHERE create_time >= '2025-01-01' AND create_time -
WHERE user_id = '123'→user_id是INT，字符串比较触发隐式转换，改为WHERE user_id = 123 -
WHERE score * 2 > 100→ 列参与运算，改写为WHERE score > 50 -
WHERE status IN ('active', 'inactive')→ 若该字段只有2个值，优化器可能认为索引区分度太低，直接全表更快
复合索引下type=ref但效果差？检查是否满足最左前缀
对联合索引(a, b, c)，WHERE b = ? AND c = ?不会走索引，WHERE a = ? AND c = ?只能用上a部分——type可能是ref，但key_len会暴露实际用了几个字节。
- 用
EXPLAIN FORMAT=TREE看更准：它会标出“Using index condition”，说明ICP（索引条件下推）生效；若没这句，意味着b和c条件是在Server层过滤，大量回表后才筛 -
key_len值突然变小（比如从10降到4），说明只用了联合索引第一列，后面列没参与查找 - 高频查询
WHERE b > ?又想走(a,b)索引？MySQL 8.0+支持跳过前导列（前提是前导列是等值），但需确认统计信息最新：ANALYZE TABLE tbl_name
Extra里藏了type背后的真相
type只是表层，Extra才是关键补丁。同一个type=ref，Extra不同，性能天差地别。
- 看到
Using where; Using index：覆盖索引，不用回表，理想状态 - 只有
Using where没Using index：走了索引定位，但还要回主键聚簇索引取其他字段 - 出现
Using filesort或Using temporary：ORDER BY或GROUP BY没走索引，强制内存/磁盘排序 -
Filter: (t1.id > 100)这种带符号的提示：条件没下推到存储引擎，说明索引设计或写法有问题
真正卡住性能的，往往不是没建索引，而是type看起来还行，但Extra暴露出大量无效回表或Server层过滤。盯住key_len和rows的匹配度，再结合FORMAT=TREE确认条件是否下推——这才是调优闭环里最容易被跳过的一步。
