MySQL生产环境定位全表扫描慢事务的排查方法

判断一条SQL语句是否正在执行全表扫描，最直接的方法就是查看`EXPLAIN`输出中的`type`字段。如果该字段显示为`ALL`，那就意味着确实没有使用索引——不是“可能”，而是确凿无疑。除此之外，还有几个关键信号值得重点关注：`key`字段为`NULL`、`rows`数量接近总行数、`Extra`里出现`Using where`但没有`Using index`。这些信号组合在一起，基本可以断定MySQL正在被迫执行全表扫描，性能堪忧。 ## 怎么快速揪出正在全表扫描的 SQL？ 不必等到慢查询日志积累大量数据后再去分析。直接连接生产数据库，执行`SHOW PROCESSLIST`命令，查看当前活跃会话中哪些正在扫描大表： - `State`是`Sending data`且`Time`超过几秒，大概率是在扫描； - `Info`字段里包含`SELECT` + 大量`WHERE`条件但缺少`ORDER BY`或`LIMIT`，尤其要留意有没有函数调用（比如`DATE(created_at)`这种）； - 配合`INFORMATION_SCHEMA.PROCESSLIST`查询更全面：`SELECT ID, INFO, TIME FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 3 AND INFO LIKE '%SELECT%';` ## EXPLAIN 里哪些信号说明它在全表扫描？ `EXPLAIN`不是走马观花，重点盯住三个字段： - `type`是`ALL`：确凿证据，没有使用任何索引； - `key`是`NULL`：即使`possible_keys`有值，`key`为空也等于索引未被采用； - `rows`数字极大（比如超过50000）：哪怕`type`是`index`，扫描整棵索引树也等价于全表扫描； - `Extra`出现`Using where`但没`Using index`：说明查询使用了索引还需要回表，如果`rows`很大，实际开销接近全表扫描。 ## 为什么明明建了索引还全表扫描？常见失效场景 索引存在 ≠ 被使用。以下几种写法会让MySQL直接放弃索引： - WHERE中对字段使用了函数：`WHERE YEAR(create_time) = 2026` → 改为`WHERE create_time >= '2026-01-01' AND create_time < '2027-01-01'`； - 隐式类型转换：`WHERE user_id = '123'`（`user_id`是INT类型）→ 字符串强制转为数字，索引失效； - LIKE左模糊：`WHERE name LIKE '%abc'` → 无法走B+树前缀匹配； - 联合索引顺序错误：`INDEX(a,b,c)`，但查询只用`WHERE c = 1` → 不满足最左前缀原则，直接跳过。 ## 线上不敢随便改 SQL？先加索引试试 如果确认是缺失索引导致的`ALL`，添加索引比重写业务逻辑快得多，但需要注意： - 优先覆盖`WHERE`条件字段，再追加`ORDER BY`和`SELECT`字段（做成覆盖索引）； - 避免单列索引堆砌，比如`WHERE a=1 AND b=2`，建`INDEX(a,b)`比分别建两个单列索引更好； - 加索引前使用`pt-online-schema-change`或MySQL 8.0+的`ALGORITHM=INSTANT`，避免锁表； - 加完索引后立即用`EXPLAIN`验证，不要相信“应该能走”。 全表扫描本身并不致命，致命的是它出现在高频接口或大表上。真正麻烦的是那些`rows`显示几千、但实际执行扫了百万行的SQL——`EXPLAIN`的预估不准时，需要借助`SHOW PROFILE`或性能模式（`performance_schema`）查看真实I/O开销。