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

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：指定慢查询日志的输出方式。my.ini0表示输出到文件，my.ini1表示输出到my.ini2表。通常建议输出到文件，因为写入表可能会对数据库性能造成轻微影响，且表数据量大时管理不便。

修改配置文件后，需要重启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语句，包括执行了多久、用了什么索引（或者根本没用）、扫描了多少行数据等等。

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

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

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

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

另外两个很有用的参数是my.ini5和my.ini6。

如知AI笔记

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

27

查看详情

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

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

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

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

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

一个简单的例子：

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

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

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

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

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

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