导读:本期聚焦于小伙伴创作的《mysql如何优化主从架构下的慢查询记录,从库慢日志怎么开启》,敬请观看详情,探索知识的价值。以下视频、文章将为您系统阐述其核心内容与价值。如果您觉得《mysql如何优化主从架构下的慢查询记录,从库慢日志怎么开启》有用,将其分享出去将是对创作者最好的鼓励。

在mysql主从架构的实际使用场景中,从库除了承担数据同步的任务,很多时候还会承接读请求,一旦出现慢查询不仅会影响读请求响应速度,还可能导致主从同步延迟加剧。因此做好主从架构下的慢查询记录优化,以及正确开启从库慢日志是数据库运维的重要工作。

mysql如何优化主从架构下的慢查询记录,从库慢日志怎么开启

从库慢查询日志开启步骤

mysql的慢查询日志默认是关闭状态,从库开启慢日志需要通过参数配置实现,分为临时开启和永久开启两种方式,生产环境建议优先选择永久配置避免重启后失效。

临时开启(重启后失效)

可以直接通过sql命令修改全局参数,执行以下命令即可开启从库慢日志:

-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
-- 设置慢查询阈值,单位秒,默认10秒,建议设置为1秒
SET GLOBAL long_query_time = 1;
-- 设置慢日志存储路径,需要保证mysql进程有写入权限
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
-- 记录未使用索引的查询,方便排查索引问题
SET GLOBAL log_queries_not_using_indexes = 'ON';

永久开启(重启后生效)

需要修改mysql的配置文件my.cnf(或my.ini,根据系统不同路径不同),在[mysqld]模块下添加以下配置:

[mysqld]
# 开启慢查询日志
slow_query_log = ON
# 慢查询阈值,单位秒
long_query_time = 1
# 慢日志文件路径
slow_query_log_file = /var/log/mysql/slow.log
# 记录未使用索引的查询
log_queries_not_using_indexes = ON

修改完成后重启mysql服务即可生效,重启后可以通过下面的命令验证是否开启成功:

-- 查看慢查询日志是否开启
SHOW VARIABLES LIKE 'slow_query_log';
-- 查看慢查询阈值
SHOW VARIABLES LIKE 'long_query_time';
-- 查看慢日志文件路径
SHOW VARIABLES LIKE 'slow_query_log_file';

主从架构下慢查询记录优化方法

开启慢日志后,还需要结合主从架构的特性做针对性优化,才能更高效地定位和解决慢查询问题。

1. 区分主从慢查询的职责

主库的慢查询大多和写操作、事务相关,从库的慢查询更多和读操作、同步回放相关。建议在慢日志文件名中加上从库标识,比如slow_slave_1.log,方便后续排查时快速区分日志来源,避免和主库日志混淆。

2. 调整慢日志参数适配从库场景

从库如果承接大量读请求,long_query_time可以适当调小,比如设置为0.5秒,更早捕获潜在的慢查询;如果仅用于数据同步,阈值可以设置为2秒,避免记录过多正常的同步回放日志。另外log_queries_not_using_indexes建议开启,从库的读查询如果没有索引会严重影响性能。

3. 定期清理和分析慢日志

慢日志会持续增长占用磁盘空间,建议定期用mysqldumpslow工具分析日志,找出执行次数最多、耗时最长的查询。分析命令示例如下:

# 按照查询总耗时排序,取前10条
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
# 按照查询次数排序,取前10条
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log

4. 针对从库慢查询做专项优化

从库的慢查询如果是同步回放产生的,需要检查主库的写操作是否过于集中,或者是否有大事务;如果是读请求产生的,需要检查查询是否缺少合适索引、是否存在全表扫描、是否可以拆分复杂查询。同时要注意从库的硬件配置是否和主库匹配,避免硬件瓶颈导致查询变慢。

5. 避免慢日志影响从库性能

慢日志的写入本身会有一定的性能开销,如果业务高峰期发现从库性能下降,可以临时关闭log_queries_not_using_indexes参数,减少日志写入量,高峰期过后再重新开启。

注意事项

  • 慢日志文件所在目录需要设置正确的权限,保证mysql用户有读写权限,否则慢日志无法正常生成
  • 修改long_query_time参数后,已经存在的会话不会立即生效,新建立的会话才会使用新的阈值,需要确认所有业务连接都更新后再排查日志
  • 主从架构下如果从库开启了并行复制,慢日志中可能会记录到并行回放的查询,分析时需要注意区分是单个查询慢还是并行调度的问题
  • 不要长期开启慢日志不清理,避免磁盘被占满影响数据库正常运行,建议设置日志轮转策略,定期归档或删除旧的慢日志

mysql主从架构慢查询日志slow_query_log数据库优化修改时间:2026-06-23 12:00:30

免责声明:​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰,观点力求客观中立。本站旨在免费分享,内容仅供个人学习、研究或参考使用。若引用了第三方作品,版权归原作者所有。如内容涉及您的权益,请联系我们处理。
内容垂直聚焦
专注技术核心技术栏目,确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计,为用户提供无干扰的纯技术知识沉淀,精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进,构建清晰学习路径,帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈,深入技术细节与实践难点。无论是数据库优化还是服务器配置,均结合真实场景与代码示例进行剖析,致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程,从数据库操作到服务器运维,形成完整闭环,一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性,步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目,显著缩短从学习到实践的距离,快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代,紧跟主流技术发展趋势,为用户提供经久不衰的学习价值。