MySQL 慢查询先查哪条：performance_schema digest Top-20 只读脚本与判读

执行 `SHOW VARIABLES LIKE 'performance_schema';`，必须是 ON。再看 `SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest;`——如果长期是 0，多半是消费者没开，或者实例刚启动还没有任何语句。

普通已认证账号一般就能读这张摘要表；读不到时不要擅自 `UPDATE performance_schema.setup_consumers`，那是生产变更，交给负责人。

摘要是累计值，不是“最近五分钟”。我这次测试库刚建完，所以 Top-1 居然是建数用的 INSERT——生产里对应批处理/导入，要先和业务确认是不是预期负载，再决定是否进优化清单。

脚本不包含任何 SET/DDL。客户端侧请自己设超时（例如 mysql 会话 `max_execution_time`，或连接工具的 query timeout）。用 `mysql -N -B shop < mysql-slow-query-topn-digest-readonly-v1.0.sql > topn.tsv` 可直接落盘。

我故意让 `SELECT COUNT(*) FROM orders WHERE uid=?` 在没有 uid 索引的情况下跑 40 次。脚本里它排第二：calls=40，total_s=0.913，mean_s=0.0228，占 38.4% 总时间，avg_rows_examined=200000，no_index_used=40。排第一的是建数 INSERT（total_s=1.263），我把它标成“预期负载”跳过。

接着用 `EXPLAIN ANALYZE SELECT COUNT(*) FROM orders WHERE uid=7;`：执行计划是 Table scan on orders，actual time=29.8 ms，扫描 200000 行。加上 `INDEX idx_orders_uid (uid)` 后再测同一条：变成 Covering index lookup，actual time=0.075 ms。测试机、自造数据，只说明方向，不是生产 SLA。

第一，Digest 文本里的关键字会被规范化成大写，例如 `status` 变成 `STATUS`。对照应用代码时按语义搜，不要精确字符串匹配。

第二，摘要表不会按“最近 N 分钟”自动切窗。实例跑了三个月，排第一的可能是早已下线的接口。生产上可以看 FIRST_SEEN / LAST_SEEN，必要时在低峰由负责人决定是否 `TRUNCATE` 摘要表——脚本本身不会做这件事。

SQL 和本次测试输出的 CSV 都可以直接下载。样例 CSV 就是上面测试库的原始 Top-20，可用来对照列含义。