真正缺索引的sql需同时满足：rows_examined接近表总行数、explain中type为all或index、key为null；应结合mysqldumpslow聚合与performance_schema的sum_rows_examined筛选，并用explain验证。
怎么看慢查询日志里真正缺索引的 SQL？
直接看 slow_query_log 文件或 performance_schema.events_statements_summary_by_digest 表，90% 的“慢语句”其实不是因为没索引，而是因为 WHERE 条件用了函数、隐式类型转换、或者 ORDER BY + LIMIT 越界扫描。真缺索引的，往往满足三个特征：全表扫描（rows_examined 接近表总行数）、type 是 ALL 或 index、且 key 字段为 NULL。
实操建议：
- 用
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log快速聚合最耗时的模板，但别只信Count和Time，要结合Rows_examined判断扫描量 - 对高频慢语句，用
EXPLAIN FORMAT=TRADITIONAL重放执行计划，重点盯type、possible_keys、key、rows四列 - 避免被
Using filesort或Using temporary干扰判断——它们是性能问题，但不等于缺索引；缺索引的核心信号是type = ALL且无key
如何用 performance_schema 定位“本可走索引却没走”的语句？
MySQL 5.6+ 的 performance_schema 能记录每条语句实际使用的索引和扫描行数，比慢日志更准、更细。关键表是 events_statements_summary_by_digest 和 events_statements_history_long，配合 setup_consumers 开关控制采集粒度。
实操建议：
- 先确认已开启：
UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'events_statements_history_long'; - 查高扫描量语句：
SELECT DIGEST_TEXT, SUM_ROWS_EXAMINED, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest WHERE SUM_ROWS_EXAMINED > 10000 ORDER BY SUM_ROWS_EXAMINED DESC LIMIT 5; - 拿到
DIGEST后，从events_statements_history_long中捞出具体语句和SQL_TEXT，再用EXPLAIN验证是否真没走索引 - 注意
SUM_ROWS_EXAMINED是累计值，单次执行可能不慢，但高频调用会拖垮整体 I/O——这类语句最容易被忽略
为什么加了索引还是慢？常见误判点有哪些？
很多 DBA 看到 EXPLAIN 显示 key != NULL 就以为“有索引了”，结果线上还是慢。本质是索引没覆盖查询需求，或选择性太低。
实操建议：
-
WHERE a = ? AND b = ?建了(a)单列索引，但没建(a,b)联合索引 → 实际只用上a，b还是回表过滤 -
WHERE status IN ('pending','processing') AND created_at > '2024-01-01'，如果status只有 3 个值，这个索引基本无效（选择性太低） -
ORDER BY create_time DESC LIMIT 20没加create_time索引，即使WHERE有索引，也会触发filesort，而排序字段没索引时，MySQL 往往放弃走索引做范围扫描 - 使用
JSON_CONTAINS()、LIKE '%abc'、DATE(created_at) = '2024-01-01'会导致索引失效，EXPLAIN里key会变空
如何验证一个索引是否真的生效且高效？
加完索引不能只看 EXPLAIN 显示 key 有值，得看它是否减少扫描行数、是否避免临时表/排序、是否在真实负载下降低 Rows_examined。
实操建议：
- 用
SELECT * FROM t WHERE ...执行两次：一次加索引前，一次加索引后，对比SHOW STATUS LIKE 'Handler_read%';中的Handler_read_next（索引遍历）和Handler_read_rnd_next（随机回表）变化 - 在业务低峰期用
pt-query-digest --explain DSN对慢日志重放，输出每条语句加索引前后的rows对比 - 监控
information_schema.INNODB_METRICS中的index_page_reads和index_page_writes，突增说明新索引被高频使用，但若innodb_buffer_pool_reads也同步涨，可能是索引太大或缓存不足 - 联合索引最左匹配不是银弹：如果查询只用
WHERE b = ?，而索引是(a,b)，那它完全不会被使用——必须检查查询条件是否严格符合最左前缀
真正难的不是加索引，是判断“这个字段组合到底该不该建索引”。它取决于查询模式、数据分布、更新频率三者博弈。比如写多读少的表，加索引反而拖慢写入；而 created_at 这种单调递增字段，建索引后容易引发页分裂，得配合 innodb_fill_factor 调整。
