performance_schema.events_statements_summary_by_digest表是定位索引缺失SQL的第一站，因其聚合去重、提供SUM_NO_INDEX_USED和SUM_NO_GOOD_INDEX_USED等硬指标，精准识别高频无索引或劣质索引查询，远超慢日志工具的模糊统计。
直接看 performance_schema.events_statements_summary_by_digest 表，比翻日志文件快得多，也更准——它自动聚合、去重、统计索引缺失次数，是定位“最该加索引”的 SQL 的第一站。
为什么不用 mysqldumpslow 或直接 grep 慢日志？
因为慢日志只记录“执行慢”，不区分原因：一条 SQL 慢，可能是数据量大、锁等待、网络抖动，也可能是没走索引。而 SUM_NO_INDEX_USED 和 SUM_NO_GOOD_INDEX_USED 这两个字段明确告诉你——这条语句在多次执行中，**反复因没用索引或用了劣质索引被 MySQL 主动标记**，这才是索引缺失的硬证据。
mysqldumpslow 只按时间排序，容易把“单次超时但实际有索引”的语句排前面；grep 更是连参数化都做不到，同一条 SQL 不同值会当成多条，干扰判断。
查哪张表？怎么写查询？
执行这条 SQL：
SELECT DIGEST_TEXT, COUNT_STAR, SUM_NO_INDEX_USED, SUM_NO_GOOD_INDEX_USED,
AVG_TIMER_WAIT/1000000000 AS avg_time_sec
FROM performance_schema.events_statements_summary_by_digest
WHERE SUM_NO_INDEX_USED > 0 OR SUM_NO_GOOD_INDEX_USED > 0
ORDER BY COUNT_STAR DESC
LIMIT 10;关键点：
-
DIGEST_TEXT是参数化后的 SQL 模板（比如SELECT * FROM orders WHERE user_id = ? AND status = ?），避免被不同 ID 冲散 -
COUNT_STAR表示该模板被执行次数，高频 + 无索引 = 首要优化目标 -
SUM_NO_INDEX_USED> 0：完全没走任何索引（全表扫描） -
SUM_NO_GOOD_INDEX_USED> 0：走了索引，但优化器认为该索引“不够好”（比如只用到联合索引前缀、或索引选择性太低） -
AVG_TIMER_WAIT单位是皮秒，除以1000000000转成秒，辅助判断是否真慢
查出来之后，怎么判断该建什么索引？
别急着建索引。先对每条结果做三件事：
- 用
EXPLAIN执行一次原 SQL（带真实参数），确认type是不是ALL或index，key是不是NULL - 看
WHERE条件字段顺序：如果条件是WHERE a = ? AND b > ? AND c = ?，优先建(a, b, c)联合索引，而不是单列索引 - 检查
SELECT字段：如果只查几个字段，且都在WHERE条件里，考虑覆盖索引（比如WHERE user_id = ? AND status = ?，又只查id, amount, created_at，就把这四个字段全放进索引） - 注意隐式转换：比如
phone VARCHAR字段用WHERE phone = 13800138000（传数字），会导致索引失效——查出的 SQL 里要留意这种写法
容易被忽略的坑：log_queries_not_using_indexes 不等于“没索引就记”
这个开关开启后，MySQL 只记录那些“本可以走索引但没走”的语句，前提是优化器评估后认为有可用索引。如果表根本没建任何索引，这条 SQL **不会**被记录进 events_statements_summary_by_digest 的这两个字段里——它压根不会触发“未用索引”的判定逻辑。
所以，如果你发现高频查询没出现在结果里，先 SHOW CREATE TABLE 看表结构：空索引表，得先建基础索引，再开这个开关，才能让它被捕捉到。
