如何利用MySQL慢查询日志发现潜在索引问题_通过pt-query-digest分析热点SQL-mysql教程-PHP中文网

log_queries_not_using_indexes不能长期开启，因其会记录所有未走索引的查询（含毫秒级小表查询），导致慢日志数小时内暴涨至gb级，引发磁盘满、i/o飙升、mysql写日志卡顿；应关闭该参数，改用min_examined_row_limit=1000精准捕获高扫描量sql。

如何利用mysql慢查询日志发现潜在索引问题_通过pt-query-digest分析热点sql

为什么 log_queries_not_using_indexes 不能长期开着

它会把所有没走索引的查询都记下来，哪怕 SELECT * FROM config WHERE id = 1 这种秒级小表查询也会进日志。生产环境开启后，日志文件几小时内就能涨到 GB 级，磁盘爆满、I/O 拉高、MySQL 写日志卡顿全跟着来。

真正该用的是 min_examined_row_limit：只记录扫描行数超阈值的语句。比如设为 1000，那 Rows_examined: 620016 的慢查才会被收录，既过滤掉噪音，又精准捕获“全表扫大表”这类典型索引缺失场景。

log_queries_not_using_indexes = OFF（默认关，别手抖开）
min_examined_row_limit = 1000（中小表可设 500，大表可调至 5000）
临时排查索引覆盖问题时，才短时间开 log_queries_not_using_indexes，并配合 long_query_time = 0 一起用

pt-query-digest 怎么筛出“假快真伤”的 SQL

有些 SQL Query_time 看着不到 100ms，但 Rows_examined 动辄几十万——说明它靠索引快速定位了结果，却因 SELECT * 或 WHERE 条件松散，导致回表或临时表膨胀。这类 SQL 在高峰期极易演变成雪崩点。

pt-query-digest 默认按响应时间排序，容易漏掉它们。必须加参数聚焦扫描量：

pt-query-digest --filter '$event->{Rows_examined} > 10000' /var/lib/mysql/mysql-slow.log
pt-query-digest --group-by fingerprint --order-by 'sum(Rows_examined) DESC' /var/lib/mysql/mysql-slow.log
重点关注报告里 “Rows_examined / Rows_sent 比值 > 100” 的条目，比如 Rows_examined: 482312 但 Rows_sent: 3，基本就是缺复合索引或 ORDER BY 未命中索引

EXPLAIN 里 key_len 异常小，往往意味着索引没用全

比如你建了联合索引 INDEX idx_user_status_created (user_id, status, created_at)，但 EXPLAIN 显示 key_len: 8（只用了 user_id 的 4 字节 + status 的 1 字节？不对），实际应是 user_id（BIGINT=8）+ status（TINYINT=1）= 9 —— 出现 8 只能说明 status 是 NULLABLE，或者查询条件里写了 status IS NULL，导致索引截断。

财经热点新闻爬取与话题归纳系统

抓取主流财经网站实时热点，提供混合评分与专业HTML报告，支持快讯采集和话题归纳。

下载

更隐蔽的是隐式类型转换：WHERE user_id = '123'（字符串）对比 BIGINT 字段，MySQL 会放弃索引下推，key_len 直接缩水。检查方法很简单：

确认字段定义：SHOW CREATE TABLE users;
比对查询条件类型是否与字段类型一致，尤其注意数字型字段别传字符串
用 EXPLAIN FORMAT=JSON 看 used_columns 和 range_possible_keys，比传统 EXPLAIN 更准

pt-query-digest 报告里 “distinct queries” 数量暴增，说明什么

如果报告顶部显示 2345 distinct queries，但其中前 10 名只占总执行次数的 12%，大概率是业务在拼接动态 SQL：比如 WHERE order_id IN (1,2,3,...,N) 每次 N 不同，或 ORDER BY ? 绑定不同字段名。MySQL 无法复用执行计划，每条都当新 SQL 编译，CPU 耗在解析上，缓存命中率暴跌。

这种问题 slow_query_log 本身抓不到（单条不慢），但 pt-query-digest 的指纹聚合会暴露出来。解决方向很明确：