Extra 列是什么
MySQL 的 EXPLAIN 输出里，Extra 用简短文字说明过滤与排序发生在哪一层：存储引擎层还是 Server 层，需不需要回表，有没有额外的排序或临时表。它比 type 列更接近性能真相，慢查询定位通常从这里开始。
基本信息
| Using where | 存储引擎返回行后，Server 层还要按 WHERE 再过滤 |
|---|---|
| Using index | 覆盖索引：查询所需列都在索引里，不需要回表 |
| Using index condition | 索引条件下推：部分条件下推到引擎层完成过滤 |
| Using filesort | 需要额外排序步骤，数据量大时会用到磁盘 |
| Using temporary | 使用内部临时表，常见于 GROUP BY、DISTINCT、UNION |
| Using join buffer | 连接使用连接缓冲；标注 hash join 的是 8.0.18+ 哈希连接 |
| Using index for skip scan | 8.0.13+ 跳跃扫描，未用前导列也能利用后续列 |
两个典型例子
两个典型例子
EXPLAIN SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;
-- Extra 可能是：Using index; Using temporary
-- 含义：查询列被索引覆盖，但仍需临时表完成分组
EXPLAIN SELECT * FROM orders WHERE user_id = 100 ORDER BY created_at LIMIT 10;
-- Extra 可能是：Using where; Using filesort
-- 含义：还需要回表，并且排序没能借助索引顺序完成常见标记与含义
| 标记 | 含义 | 优化提示 |
|---|---|---|
| Using where | Server 层还有过滤条件 | 让过滤列尽量进入索引 |
| Using index | 覆盖索引，无需回表 | SELECT 写明确列名更容易达成 |
| Using index condition | 索引条件下推生效 | 减少回表次数，通常是好事 |
| Using filesort | 存在额外排序步骤 | 让 ORDER BY 与索引顺序一致 |
| Using temporary | 使用内部临时表 | 优化分组键或补充索引 |
| Using join buffer (hash join) | 使用哈希连接 | 等值连接缺少索引时的兜底方案 |
典型使用场景
- 慢查询定位：先看 type 再读 Extra，判断瓶颈在哪一层
- 索引评审：确认新加的索引是否被用上、是否达成覆盖
- 排序优化：消除 filesort，让 ORDER BY 顺着索引顺序走
- 分组优化：减少 Using temporary 的出现频率
- 上线前回归：对比优化前后 Extra 的变化
- 向同事解释执行计划：Extra 是最直观的证据
Extra 里同时出现 Using index 与 Using where 并不矛盾：前者说明查询列被索引覆盖、不用回表，后者说明仍有过滤动作发生在 Server 层，两件事互相独立，可以同时成立。
Using filesort 不代表一定用了磁盘：排序数据量小于排序缓冲区时是在内存里完成的。先看扫描行数与结果行数，再决定是否为消除排序去调整索引。