mysql如何开启slow query log-mysql教程-PHP中文网

mysql如何开启slow query log

P粉602998670

发布： 2025-09-25 15:49:01

原创

944人浏览过

开启MySQL慢查询日志需修改配置文件或动态设置参数，核心是启用slow_query_log并指定long_query_time阈值，将执行时间超过设定值的SQL记录到文件，便于后续使用mysqldumpslow或pt-query-digest分析性能瓶颈，优化数据库查询效率。

mysql如何开启slow query log

MySQL开启慢查询日志，核心操作就是修改配置文件或在运行时设置参数。这就像给你的数据库装上一个“行车记录仪”，专门记录那些跑得慢、耗时长的SQL语句，是性能调优的第一步，也是最关键的一步。

解决方案

要开启MySQL的慢查询日志，最常见也最稳妥的方式是修改MySQL的配置文件my.cnf（Linux）或my.ini（Windows）。找到配置文件后，在[mysqld]段下添加或修改以下配置项：

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_output = FILE

登录后复制

slow_query_log = 1：这行是开启慢查询日志的关键，1代表开启，0代表关闭。
slow_query_log_file = /var/log/mysql/mysql-slow.log：指定慢查询日志文件的路径和名称。请确保MySQL用户对该目录有写入权限。如果未指定，通常会生成在数据目录下，以hostname-slow.log命名。
long_query_time = 1：设定一个阈值，单位是秒。任何执行时间超过这个值的SQL语句都会被记录下来。这里设置为1秒，意味着执行超过1秒的查询都会被视为“慢查询”。这个值需要根据你的应用实际情况来调整，有时0.5秒甚至0.1秒都算慢。
log_output = FILE：指定慢查询日志的输出方式。FILE表示输出到文件，TABLE表示输出到mysql.slow_log表。通常建议输出到文件，因为写入表可能会对数据库性能造成轻微影响，且表数据量大时管理不便。

修改配置文件后，需要重启MySQL服务才能使配置生效。

如果你不想重启服务，也可以在MySQL客户端通过SQL命令动态开启（但重启后会失效，除非也修改了配置文件）：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_output = 'FILE';

登录后复制

慢查询日志的价值在哪里？为什么我们需要它？

我常常把它看作数据库的“体检报告”，是诊断数据库性能问题的利器。你想啊，一个系统运行久了，总有些地方会“卡壳”，但你肉眼看不见。慢查询日志就是那个能精准指出“卡壳”在哪里的工具。它记录了所有超出你忍受范围的SQL语句，包括执行了多久、用了什么索引（或者根本没用）、扫描了多少行数据等等。

对我来说，它的价值不仅仅是找出“慢”的语句，更在于它能揭示出很多我们平时在开发中可能忽略的问题。比如，某个看似简单的查询，在高并发下突然就成了瓶颈；或者某个功能上线后，因为数据量增长，之前没问题的查询突然就慢了下来。有了慢查询日志，这些“盲点”就变得清晰可见。它帮助我们从数据层面理解应用的行为，而不是凭空猜测。这就像医生通过化验单来诊断病情，而不是只听病人说“我肚子疼”就开药。

如何配置慢查询日志才更合理？参数解读与实践建议

配置慢查询日志，不是简单地打开就行，关键在于“合理”。这里面有几个参数值得我们细细琢磨：

首先是long_query_time，这个阈值设置得太高，可能漏掉一些“亚健康”的查询；设置得太低，又可能产生海量的日志，占用磁盘空间，甚至影响IO性能。我通常会根据业务的响应时间要求来定。如果一个Web接口要求在200ms内响应，那么我可能会把long_query_time设为0.2秒甚至更低，这样任何可能影响用户体验的查询都能被捕捉到。但对于一些后台批处理任务，1秒甚至5秒可能都是可以接受的。这是一个动态平衡的过程，需要你对业务有足够的理解。

另外两个很有用的参数是log_queries_not_using_indexes和log_slow_admin_statements。

如知AI笔记

如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

查看详情

log_queries_not_using_indexes = 1：这个参数非常棒，它会记录那些没有使用索引的查询，即使它们的执行时间没有超过long_query_time。这对于发现潜在的性能隐患极其重要。很多时候，一个查询在数据量小的时候很快，但一旦数据量上来，没有索引就会变成灾难。开启它，能帮你提前发现这些“定时炸弹”。
log_slow_admin_statements = 1：顾名思义，它会记录一些慢的“管理语句”，比如ALTER TABLE、ANALYZE TABLE等。这些操作在生产环境有时会阻塞业务，记录下来有助于我们规划维护窗口。

至于log_output，前面提到了，我个人倾向于FILE。日志文件可以用各种工具分析，而数据库表则可能带来额外的管理负担。日志文件通常会按需轮转（logrotate），避免单个文件过大。

开启慢查询日志后，我们该如何分析这些日志？

开启日志只是第一步，更重要的是如何“读懂”这些日志。直接看原始的慢查询日志文件，密密麻麻的SQL语句，简直是噩梦。幸好，我们有工具。

最基础也最常用的就是MySQL自带的mysqldumpslow工具。它能对慢查询日志进行聚合分析，比如按访问次数、按总耗时、按平均耗时等方式对慢查询进行排序和汇总。

一个简单的例子：

mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

登录后复制

这条命令的意思是：对/var/log/mysql/mysql-slow.log这个文件进行分析，按总耗时（-s t，t代表Time）排序，并显示前10条（-t 10）慢查询。输出结果会把相同的SQL模板归类，然后给出执行次数、总耗时、平均耗时、发送到客户端的行数、扫描的行数等信息。通过这个，你就能一眼看出哪些SQL语句是“罪魁祸首”。

更高级一点的工具是Percona Toolkit中的pt-query-digest。这个工具功能强大得多，它不仅能分析慢查询日志，还能分析binlog、tcpdump抓取的网络流量等，输出的报告也更详细、更易读，甚至能给出优化建议。它能识别出查询中的参数，将SQL语句模板化，这对于分析动态SQL非常有用。

分析慢查询日志时，我通常会关注几个点：

高频次且耗时长的查询：这通常是应用的核心功能，优化它们能带来显著的性能提升。
扫描行数远大于返回行数的查询：这往往意味着没有用到合适的索引，或者索引失效，导致全表扫描或大量数据过滤。
锁等待时间长的查询：虽然慢查询日志不直接显示锁信息，但如果一个查询因为等待锁而变慢，它也会被记录下来。这提示我们需要检查事务隔离级别、事务粒度以及并发操作。
使用了ORDER BY、GROUP BY但没有对应索引的查询：这些操作如果没有索引支持，可能会产生临时表，非常耗费资源。

分析是一个迭代的过程：发现问题 -> 优化SQL/索引 -> 观察日志 -> 再次优化。这是一个持续改进的过程，没有一劳永逸的解决方案。

以上就是mysql如何开启slow query log的详细内容，更多请关注php中文网其它相关文章！