using index表示覆盖索引生效，即mysql仅通过索引叶子节点获取全部查询字段，无需回表；其前提是select、where、order by等所有涉及字段均被同一索引包含且满足最左前缀原则。
Extra字段是EXPLAIN输出里最贴近实际执行动作的信号灯——它不告诉你“理论上怎么走”，而是直接暴露MySQL在真实执行时做了什么额外操作。
Using index 表示索引已足够，连表数据都不用读
当Extra显示Using index，说明查询所需的所有字段（包括SELECT列和WHERE条件列）都落在同一个索引里，MySQL只扫描索引树就完成了全部工作，完全跳过了聚簇索引回表。这叫“覆盖索引”。
- 常见于组合索引上只查前缀字段，比如索引是
(user_id, status, created_at)，而语句是SELECT user_id, status FROM orders WHERE user_id = 123 - 如果
SELECT *或WHERE里用了未包含在该索引中的字段，就不会出现Using index，哪怕其他条件命中了索引 - 注意：只有InnoDB支持真正的覆盖索引；MyISAM即使显示
Using index，也可能仍需访问数据文件
Using where 和 Using index condition 容易混淆，但行为完全不同
Using where意味着MySQL在拿到索引扫描结果后，还要在Server层对每行做一次过滤；而Using index condition（ICP）是把部分WHERE条件下推到存储引擎层，在索引遍历阶段就筛掉不匹配项，减少回表次数。
-
Using where常见于WHERE age > 25这种范围条件，且age没索引或不是索引最左前缀 -
Using index condition需要满足：使用二级索引 + 条件中含该索引的部分字段 + 这些字段支持下推（如=、IN、>、LIKE 'abc%'），但LIKE '%abc'不行 - 开启ICP（默认开启）能显著降低回表I/O，尤其在大结果集+高过滤率场景下；可通过
SET optimizer_switch='index_condition_pushdown=off'临时关闭验证效果
Using filesort 和 Using temporary 是性能红灯，但成因常被误判
这两个值不是“排序慢”或“建临时表”的结果描述，而是明确告诉MySQL：“我找不到现成有序的数据流，必须自己搞一套”。它们本身不等于慢，但大概率意味着索引设计或查询写法有优化空间。
-
Using filesort不一定真写磁盘文件——小结果集在内存排序，但只要没走ORDER BY字段的索引，就会标记这个值 -
Using temporary常见于GROUP BY或DISTINCT没走索引，或UNION中间结果合并；但注意：GROUP BY字段和SELECT字段一致且有索引时，可能不触发临时表 - 联合索引顺序很关键：想让
ORDER BY a, b免filesort，索引必须是(a, b)而非(b, a)；WHERE a = ? ORDER BY b则(a, b)同样有效
Impossible WHERE 和 const row not found 这类值容易被忽略，但代表逻辑异常
它们不是性能问题，而是SQL语义层面的信号：Impossible WHERE说明WHERE条件永远为假（比如WHERE 1=0或id = 5 AND id = 6），MySQL压根不会去查表；const row not found则是试图从空表查const级别数据（如SELECT * FROM empty_table WHERE id = 1）。
- 线上突然出现大量
Impossible WHERE，可能是应用拼接SQL时参数为空或类型错误导致条件恒假 - 这类值在慢日志里几乎不会出现（因为根本不执行），但会出现在监控采集的EXPLAIN样本中，是排查业务逻辑错漏的重要线索
- 不要只盯着
rows或type，Extra里这些“非性能类”提示往往指向更底层的问题
真正难的不是看懂每个Extra字面意思，而是结合key、key_len、rows和实际数据分布，判断这个“额外动作”是不是必要、能不能避免。比如Using where和Using index condition同时出现，说明部分条件走了ICP、部分还在Server层过滤——这时候就要检查索引字段顺序和条件写法是否还能收紧。
