慢查询日志真正生效需同时满足：slow_query_log_file为非空绝对路径且目录权限正确、long_query_time为浮点数、执行sleep后日志可查；禁用table输出和log_queries_not_using_indexes；long_query_time应按业务节奏调整；分析须用pt-query-digest看总耗时占比并结合explain验证。
确认 slow_query_log 是否真正生效，而非仅显示 ON
很多线上问题不是没慢 SQL，而是日志根本没落盘。只查 @@slow_query_log 是 ON 不够，必须验证三件事同时成立：
-
@@slow_query_log_file必须是非空绝对路径（如/var/log/mysql/slow.log），不能是默认值（如/var/lib/mysql/hostname-slow.log） - 该路径所在目录需存在，且属主为
mysql用户、权限至少755；日志文件本身建议设为600 -
@@long_query_time必须是浮点数（如1.0），不能写1或ON；MySQL 5.7+ 严格校验类型，错一个就静默失败
验证方法：执行 SELECT SLEEP(2); 后立刻跑 tail -n 1 /var/log/mysql/slow.log。如果没输出，再查 SHOW GLOBAL STATUS LIKE 'Slow_queries';——若仍为 0，说明配置未触发，不是“没慢 SQL”，而是“压根没记”。
禁用 log_queries_not_using_indexes 和 TABLE 输出
这两个选项在生产环境极易放大风险：
-
log_output = TABLE会把日志写进mysql.slow_log表，加重 InnoDB 刷脏页压力，且该表默认是 CSV 引擎，无索引、查询极慢；坚持用FILE方式，便于后续用logrotate控制生命周期 -
log_queries_not_using_indexes = ON会记录所有未走索引的查询，哪怕执行仅0.01秒——大量SELECT * FROM config WHERE key='xxx'类语句极易带出敏感键名或值，增加审计面和泄露风险 - 真需要捕获未走索引的语句，优先用
pt-query-digest --filter在日志采集后过滤，而非让 MySQL 原始记录
long_query_time 取值必须匹配业务节奏，不能一刀切
long_query_time 不是“越小越好”。设成 0.1 看似精细，但会导致日志量爆炸，尤其在 OLTP 场景下每秒数百条慢查询，I/O 和磁盘空间立刻告急：
- 业务峰值期，建议先设为
2.0，观察Slow_queries计数器增长速率；若每分钟新增不足 10 条，再逐步下调到1.0或0.5 - 注意：MySQL 5.7 中
long_query_time对新连接才生效；修改后需FLUSH PRIVILEGES;或新建连接验证 - 阈值下调后务必同步检查磁盘剩余空间和
logrotate配置是否覆盖新路径
用 pt-query-digest 分析，别信 mysqldumpslow 的默认排序
mysqldumpslow 默认按单次耗时排序，但真正拖垮系统的往往不是“最慢那条”，而是“执行频次最高 + 平均耗时中等”的 SQL。必须看总耗时占比（Count × Exec time）：
- 基础命令：
pt-query-digest /var/log/mysql/slow.log --limit 10 - 关键参数：
--since '2026-09-30 14:00:00'按时间切片；--filter '$event->{db} =~ m/^prod_/'过滤库名；--no-report跳过汇总，只导出可疑语句供人工复核 - 重点关注字段：
Rows_examined远大于Rows_sent（缺索引）、Using filesort或Using temporary（排序/分组未走索引）、大偏移分页（limit 100000,10）
分析完必须回到 EXPLAIN 验证执行计划，否则优化就是拍脑袋——日志里标出的“问题 SQL”，可能只是表结构变更后临时失效的索引，而不是代码缺陷。
