怎样在MySQL中通过慢日志排查全表扫描的隐患SQL？

通过慢日志中Rows_examined接近表总行数、key为NULL且Extra含“Full scan”可判断全表扫描；需结合EXPLAIN验证type=all，并注意小表扫描可能不入慢日志。

如何确认慢日志里哪些SQL触发了全表扫描

MySQL 慢日志本身不直接标记“全表扫描”，但会记录 Rows_examined 和执行时间，这是判断的关键线索。真正触发全表扫描的 SQL 通常表现为：单次查询 Rows_examined 接近或等于表总行数，且没有用到索引（key 字段为 NULL 或空）。

实操建议：

• 先查目标表行数：SELECT COUNT(*) FROM table_name;，心里有底
• 解析慢日志时重点关注 Rows_examined 值 —— 如果它 > 表行数的 80%，基本可判定是全表扫描
• 结合 Extra 字段（需开启 log_slow_extra=ON）看是否含 Using where; Full scan on NULL key 或类似提示
• 注意区分：Rows_examined 高 ≠ 一定没索引，也可能是索引失效（如对字段做函数操作、隐式类型转换）

为什么 EXPLAIN 显示 type=all 却没进慢日志

慢日志只记录执行时间超过 long_query_time 的语句，而 EXPLAIN 中 type=all 只说明计划走全表扫描，不代表实际执行慢。小表（比如几百行）、内存足够、无并发竞争时，全表扫描可能不到 10ms，根本不会被记录。

实操建议：

• 不要只依赖慢日志找全表扫描，定期用 SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema = 'db_name' AND table_rows > 10000; 筛出大表，再针对性 EXPLAIN 其常用查询
• 把 long_query_time 设低一点（比如 0.1），配合 log_queries_not_using_indexes=ON，能捕获更多潜在隐患（但注意磁盘 IO 压力）
• log_queries_not_using_indexes 对 SELECT 有效，但对 INSERT ... SELECT 或子查询中的扫描无效，得单独分析

如何快速定位慢日志中重复出现的全表扫描模式

人工翻日志效率低，关键是用工具提取共性特征：相同表名 + 高 Rows_examined + type=all（来自后续 EXPLAIN 验证）+ 参数化后 SQL 结构一致。

实操建议：

• 用 mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log 先按耗时排序 Top 10
• 配合 grep -A 5 "Rows_examined: [1-9][0-9]{5,}" slow.log 抓高扫描行数的条目
• 对疑似 SQL 做参数归一化：把数字、字符串替换成 ?，例如 WHERE id = 123 → WHERE id = ?，再统计频次
• 注意：同一条 SQL 在不同条件下可能有时走索引、有时全表扫描（比如 WHERE status IN ('a','b') 中值分布变化导致优化器选错），不能只看一次 EXPLAIN

修复前必须验证的三个条件

加索引不是万能解药，盲目添加反而可能让写入变慢、甚至引发锁等待。修复前务必确认：

• 该 SQL 真实存在且高频 —— 查 performance_schema.events_statements_summary_by_digest 中 EXECUTIONS 和 SUM_TIMER_WAIT，别只看慢日志次数
• WHERE 条件字段的选择性够高 —— 用 SELECT COUNT(DISTINCT column_name)/COUNT(*) FROM table_name; 算选择率，低于 0.05 不建议单独建索引
• 现有索引是否被复用 —— 比如已有 (a,b) 索引，而查询是 WHERE a = ? AND b = ? ORDER BY c，加 (a,b,c) 覆盖索引比只加 c 更合理

最常被忽略的是：没检查查询是否带 LIMIT。如果 SQL 总是 LIMIT 1 且命中首行就停，即使 type=all，优化优先级也远低于无 LIMIT 的同类扫描。