通过慢日志中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 的同类扫描。
