慢查询日志必须配准、写入、可读才有效：先用show variables确认slow_query_log=on、路径可写、long_query_time合理（建议1秒起步），再用select sleep(2)实测落盘；log_queries_not_using_indexes开启时须同步设min_examined_row_limit防日志爆炸，分析时需结合lock_time和rows_examined定位锁竞争或索引失效。
慢查询日志不是“开了就能发现问题”，它得配得准、写得进、看得懂——否则你看到的要么是空白文件，要么是海量噪音。
确认 slow_query_log 是否真在记录
很多问题卡在“以为开了，其实没开”。SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 才算生效；如果返回 OFF 或空值，说明配置未加载或被覆盖。还要查三件事：
-
SHOW VARIABLES LIKE 'slow_query_log_file'—— 看路径是否存在，且 MySQL 进程（如用户mysql）对该目录有写权限 -
SHOW VARIABLES LIKE 'long_query_time'—— 注意它是个浮点数（如1.000000），设成1和1.0效果一样，但设成0会记录所有查询，极易撑爆磁盘 - 执行
SELECT SLEEP(2)（确保超阈值），再tail -n 5 /var/log/mysql/mysql-slow.log看是否新增记录——别只看文件存在，要实测落盘
long_query_time 设多少才不漏不炸
设太大会漏掉正在恶化的中等耗时查询（比如从 800ms 慢到 1.8s），设太小又会让日志暴涨、IO 压力陡增。生产环境建议：
- 先从
long_query_time = 1起步，观察 1–2 天日志量和典型查询耗时分布 - 若发现大量查询集中在 0.3–0.8 秒，再逐步下调到
0.5；MySQL 5.7+ 支持小数，但 5.6 只保留一位，0.098可能被截成0.09导致漏记 - 注意：
Query_time只计 SQL 执行时间，不含网络传输、连接排队、锁等待（这部分体现在Lock_time字段里）
log_queries_not_using_indexes 不开则已，一开必配 min_examined_row_limit
单独开 log_queries_not_using_indexes = ON 是自找麻烦：哪怕 WHERE id = -1 这种永远查不到的语句，只要没走索引，也会被记下。结果就是日志里塞满低危害全表扫描。
- 必须同步设置
min_examined_row_limit = 100（或按业务调高），表示“未走索引且扫描行数 ≥ 100 才记录” - 该参数不可动态修改（MySQL 5.7+ 原生支持，但云厂商常禁用），必须写进
/etc/mysql/my.cnf的[mysqld]段并重启 - 开启后重点盯
Rows_examined和Rows_sent的比值——扫 10 万行只返 1 行，大概率是索引缺失或条件没触发索引
分析日志时别跳过 Lock_time 和 Rows_examined
单看 Query_time 容易误判。真正暴露瓶颈的是组合字段：
- 如果
Lock_time占Query_time70% 以上 → 瓶颈不在 SQL 写法，而在锁竞争（长事务、热点行更新、间隙锁等） - 如果
Rows_examined远大于Rows_sent（比如 50000:1）→ 无效扫描，优先检查执行计划（EXPLAIN）是否走了索引、索引是否覆盖查询字段 - 用
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log按总耗时 Top 10 排序，比手动翻日志高效得多；但更推荐pt-query-digest，它自动聚合指纹、给出优化建议
最常被忽略的一点：慢查询日志只记录“执行完”的语句，那些卡在连接池排队、卡在锁队列里没开始执行的请求，它完全看不见。所以日志为空 ≠ 没瓶颈，得结合 SHOW PROCESSLIST 和性能监控一起看。
