log_queries_not_using_indexes不能长期开启，因其会记录所有未走索引的查询（含毫秒级小表查询），导致慢日志数小时内暴涨至GB级，引发磁盘满、I/O飙升、MySQL写日志卡顿；应关闭该参数，改用min_examined_row_limit=1000精准捕获高扫描量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.logpt-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，导致索引截断。
每小时自动在推特搜索中国、加密货币、国际热点、美国热点、特朗普等话题的热度信息，提取前十热点，依据 X 平台真实算法权重（开源代码数据）为每个热点生成高曝光推文或线程。用户提及“推特热点”“Twitter热点”“推特搜索”“热点推文”“生成推文”“社交媒体监控”“Twitter监控”等关键词时触发。
更隐蔽的是隐式类型转换：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 的指纹聚合会暴露出来。解决方向很明确：
- 禁止客户端拼 IN 列表，改用临时表 + JOIN
- 排序字段写死，前端通过状态位控制，而非透传列名
- 用
sys.statement_analysis查avg_timer_wait高但exec_count低的语句，比慢日志更早发现苗头
索引问题最麻烦的不是找不到，而是“看起来有索引，但根本没走全”。pt-query-digest 的价值不在汇总耗时，而在暴露那些 Rows_examined 高得反常、distinct queries 多得离谱、key_len 小得可疑的中间态异常——这些才是线上事故真正的前兆。
