MySQL 慢查询日志：先找到慢在哪里，再谈调参数

归档日期：2026-10-27；补录发布：2026-10-28。

数据库响应慢，不一定是缓冲池太小。扫描行数过多、索引不合适、锁等待或连接问题，都可能影响网站。慢查询日志提供排查入口，需要与执行计划和运行状态一起判断。

查实际值与路径

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'slow_query_log_file';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_output';

不要猜日志位置。本站调优笔记使用过 long_query_time=2，用来重点观察超过相应耗时条件的语句，但它不是所有业务的标准阈值。

读哪些线索

Query_time 是耗时线索，Lock_time 反映相关锁等待信息，Rows_sent 与 Rows_examined 帮助比较返回量和检查量。耗时高且检查行数大，值得检查过滤条件和索引；锁等待明显时还要看事务。

这些字段不能直接对应唯一原因。查询慢不代表增加 CPU 一定解决，读取行数多也需结合表规模与业务目的。

配置与运行状态分开

写进 /etc/my.cnf.d/mysql-server.cnf 的参数是否加载，要查询运行变量。动态修改与持久化也不同，未保存的修改可能重启后消失；MySQL 还有持久化变量机制，排查时要注意配置来源。

不要为一项参数立即重启数据库，先确认支持的修改方式、影响和维护窗口。

记录本身也有成本

阈值过低会增加日志量。general_log 记录范围更广，开销与信息暴露风险需要另行评估，不能把它当慢日志的默认替代品。

日志可能含业务数据和查询参数，分享前应脱敏，文件权限、轮转与磁盘空间也需考虑。

如何继续分析

按时间对齐网站异常与慢日志，找出重复的查询类型，在合适环境分析执行计划。优化前后比较耗时、扫描量和错误，一次尽量只改一个变量。

本文记录使用方法，没有把未经基线验证的参数修改写成确定的性能提升。

阈值变更不一定影响旧连接

long_query_time 有会话与全局层面的区别，修改全局值后已存在会话可能保留原值。复查时用新会话查看，并记录具体修改方式；不要随便断开全部业务连接。慢日志中的 Lock_time 也不是所有 InnoDB 行锁等待的完整度量，要结合 performance_schema 与事务情况。日志没有记录不代表所有查询都快，先确认记录开启、输出位置与阈值。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。