type字段表示mysql查找数据的访问类型，性能从优到劣为system≈const>eq_ref>ref>range>index>all；all是全表扫描，效率最低，需优先优化。
type字段怎么看：从ALL到const，访问方式直接决定快慢
type是EXPLAIN里最该盯住的一列，它不讲“用了什么索引”，而讲“MySQL实际怎么捞数据”。性能排序是：system ≈ const > eq_ref > ref > range > index > ALL。你看到ALL，基本等于没走索引——哪怕表上明明建了索引。
常见误判点：
-
IN里值太多（比如上百个）会退化成ALL，不是语法错，是优化器主动放弃索引 -
index看着比ALL好，但其实是整棵索引树扫描，和全表扫描I/O量接近，也要优化 -
ref和range之间没绝对优劣：WHERE status = 'paid'是ref，WHERE created_at > '2025-01-01'是range；但如果status字段只有两个值，选择性差，优化器可能跳过索引选ALL
Extra字段里哪些值必须立刻处理
Extra是执行过程的“异常日志”，出现以下任意一项，说明查询已偏离高效路径：
-
Using filesort：ORDER BY没走索引，MySQL自己在内存或磁盘排序——加联合索引时，要把ORDER BY字段放在最后，比如INDEX(user_id, created_at)支持WHERE user_id = 123 ORDER BY created_at -
Using temporary：GROUP BY、DISTINCT或某些JOIN触发了临时表，尤其当Rows_examined远大于Rows_sent时，大概率是这里卡住 -
Using index condition：说明用了ICP（索引条件下推），是好事；但若同时出现Using where，代表索引没覆盖全部WHERE条件，剩余部分还得回表 -
Impossible WHERE或Using join buffer：前者是逻辑矛盾（如id = 1 AND id = 2），后者说明JOIN没走索引，buffer在硬扛
key和possible_keys不一致，到底信谁
possible_keys是MySQL“觉得能用”的索引列表，key是它“拍板用”的那个。两者不一致很常见，但要分清原因：
-
possible_keys有值，key却是NULL：不是没索引，而是优化器算出来走索引比全表扫描还慢（比如小表、字段重复值过多） -
key选了低效索引：比如你建了INDEX(a, b, c)，但查询只写了WHERE b = 2，MySQL可能弃用这个索引，改用其他单列索引甚至ALL；这时可加FORCE INDEX(a,b,c)验证效果 -
key_len明显偏小：比如INDEX(a, b)理论上最大长度是8字节，但key_len只显示4，说明只用到了a列，b被跳过了——检查WHERE是否漏了a的等值条件
为什么EXPLAIN说走了索引，但SQL还是慢
EXPLAIN只模拟执行计划，不真正跑SQL，所以它看不到真实瓶颈。几个典型脱节场景：
- 统计信息过期：
ANALYZE TABLE table_name强制刷新后，type可能从ALL变成ref - 隐式类型转换：字段是
INT，但写成WHERE user_id = '123'（字符串），索引失效，type直接掉到ALL - 函数包裹字段：
WHERE YEAR(created_at) = 2025或WHERE UPPER(name) = 'JOHN'，索引无法下推，Extra里不会报错，但type必然恶化 - 结果集太大触发磁盘临时表：即使
type是ref、Extra干净，只要SELECT里含TEXT/BLOB或行数超内存阈值，就会落到磁盘，I/O飙升
真正卡住的地方，往往藏在rows和filtered的组合里：rows是预估扫描行数，filtered是过滤后剩多少百分比。如果rows是10万，filtered是1%，实际只取1000行——那前面9.9万行就是白扫的，得从WHERE条件的选择性入手，而不是只盯着索引有没有。
