慢查询日志：从开启到分析，避开那些“开了等于没开”的坑
想优化数据库性能，慢查询日志是绕不开的起点。但这里有个常见的误区：你以为开启了全局日志就万事大吉？如果关键的阈值没设对，很可能跑上一天也抓不到一条有效记录。而在分析工具的选择上，pt-query-digest凭借其SQL归一化、细粒度指标分析和灵活的时间切片能力，已经全面超越了老牌的mysqldumpslow，成为更精准、更实用的选择。
如何确认并正确开启 slow_query_log
动手之前，先别凭感觉，务必确认当前状态。否则，你可能在对着一个空的日志文件做无用功。
- 用
SHOW VARIABLES LIKE 'slow_query_log';看一眼，如果返回OFF，那就说明根本没开。 - 再看
SHOW VARIABLES LIKE 'long_query_time';，默认值10.000000意味着只记录执行超过10秒的查询——这在生产环境里，几乎等于什么都抓不到。 - 临时开启（注意，必须在全局级别设置）：执行
SET GLOBAL slow_query_log = ON;，同时把SET GLOBAL long_query_time = 0.5;（建议值在0.5到2秒之间，支持小数）。 - 如果不指定路径，日志文件默认会放在MySQL的数据目录下，名字类似
hostname-slow.log，记得确保MySQL进程对这个路径有写入权限。 - 如果想一网打尽那些“没走索引”的语句，可以再加一条：
SET GLOBAL log_queries_not_using_indexes = ON;。
配置文件里怎么写才不会重启失败
临时生效的配置重启就没了，所以必须写入配置文件。修改 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段落时，有几个细节容易踩坑：
- 别写
slow_query_log = ON，尤其是在MySQL 8.0+版本，要求写成slow_query_log = 1，否则服务可能启动失败。 slow_query_log_file指定的路径必须真实存在且MySQL用户可写。比如设成/var/log/mysql/slow.log，就得提前执行mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql。- 把
long_query_time设为0.1能捕获到毫秒级的毛刺，但日志体积会爆炸式增长，不适合长期开启。 - 加上
log_output = FILE明确输出到文件。这是为了避免某些版本默认把日志写进mysql.slow_log系统表，导致后续用pt工具分析时不便。 - 还有个可选但很实用的参数：
min_examined_row_limit = 100。它能过滤掉那些虽然执行慢、但只扫描了几行数据的干扰项（比如纯粹在等锁的查询）。
为什么不用 mysqldumpslow，而选 pt-query-digest
很多人习惯用自带的 mysqldumpslow，但它功能实在有些简陋。它不做SQL归一化，遇到带不同IN列表或LIMIT值的同构语句，就会傻傻地拆成多条统计，导致结果失真。相比之下，pt-query-digest 的优势就明显多了：
- 自动参数化SQL：像
SELECT * FROM user WHERE id = 123和id = 456这样的语句，会被智能地归为同一类，统计更准确。 - 支持按时间范围切片：你可以用
--since '2026-04-10 22:00:00'这样的参数，只分析特定时间段内的日志，排查问题更高效。 - 关键指标一目了然：报告能直接识别并标出锁等待时间、扫描行数(
Rows_examined)、返回行数等核心指标，帮你快速定位问题SQL。 - 生态衔接好：输出报告里的“Query ID”，可以直接给
pt-query-advisor等工具使用，进一步获取优化建议。 - 安装简单：主流系统基本都有包，Debian系用
apt install percona-toolkit，CentOS用yum install percona-toolkit，装完即用。
分析时最容易被忽略的三个细节
跑完 pt-query-digest，很多人直奔“最慢的Top 10”语句，但往往优化了半天效果不彰。问题出在哪儿？真正值得关注的，往往是这些细节：
Rows_examined远大于Rows_sent：这几乎是索引问题的“铁证”。说明SQL为了返回少量数据，扫描了大量无关行，大概率是缺索引，或者索引因为对字段用了函数等原因失效了。- 报告里大量出现
Using temporary; Using filesort：这通常不是单条SQL能轻易优化的。它暗示了更深层的设计问题，比如分页逻辑不合理，可能需要考虑用覆盖索引来规避临时表和文件排序。 - 同一类Query ID的
Count极高，但平均Exec time很短：比如某类查询被执行了10万次，平均耗时却只有几毫秒。这时候，瓶颈很可能不在SQL本身，而是连接池配置、网络往返延迟或应用层频繁创建连接等问题。
说到底，日志分析的核心目标，不是找到“最慢的一条”SQL，而是定位“对系统影响面最大的一类”问题。把握住这个原则，优化才能事半功倍。
