开启MySQL慢查询日志需修改配置文件my.cnf或my.ini，在[mysqld]段添加slow_query_log、slow_query_log_file、long_query_time和log_queries_not_using_indexes参数，确保日志路径权限正确，重启MySQL服务后通过SHOW VARIABLES验证配置，并利用mysqldumpslow或pt-query-digest工具分析日志以优化性能。

开启MySQL慢查询日志，核心在于修改MySQL的配置文件my.cnf（或者my.ini，取决于操作系统），然后重启MySQL服务，让配置生效。这个过程不复杂，但它能为你的数据库性能优化提供最直接、最宝贵的数据支持。

解决方案

要开启MySQL的慢查询日志，你需要找到并编辑你的MySQL配置文件。通常在Linux系统上是/etc/my.cnf或/etc/mysql/my.cnf，Windows系统则在MySQL安装目录下的my.ini。

1. 定位配置文件： 如果你不确定配置文件在哪里，可以登录MySQL客户端，执行 SHOW VARIABLES LIKE '%datadir%'; 来查找数据目录，配置文件通常在数据目录的上一级或者同级。 或者，你也可以通过 ps -ef | grep mysql 命令查看MySQL进程的启动参数，通常会包含 --defaults-file= 参数指向配置文件。

2. 编辑配置文件： 使用文本编辑器（如vi或notepad）打开找到的配置文件。在my.ini0配置段下，添加或修改以下几行：

   [mysqld] # 开启慢查询日志 slow_query_log = 1 # 指定慢查询日志文件的路径和名称 slow_query_log_file = /var/log/mysql/mysql-slow.log # 定义慢查询的时间阈值，单位秒。这里设置为2秒，表示执行时间超过2秒的查询会被记录。 long_query_time = 2 # 记录没有使用索引的查询，这对优化非常重要 log_queries_not_using_indexes = 1

   注意： my.ini1 的路径需要确保MySQL用户（通常是my.ini2用户）有写入权限，并且该目录存在。如果目录不存在，你需要手动创建它：my.ini3。

3. 重启MySQL服务： 保存配置文件后，你需要重启MySQL服务以使更改生效。

   在Linux上： my.ini4 (或 my.ini5)

   在Windows上： 打开服务管理器，找到MySQL服务，右键选择“重启”。

4. 验证配置： 重启后，登录MySQL客户端，执行以下命令检查慢查询日志是否已开启并生效：

   SHOW VARIABLES LIKE '%slow_query%'; SHOW VARIABLES LIKE 'long_query_time';

   你应该能看到 my.ini6 的值为 my.ini7 (或 my.ini8)，my.ini1 指向你设置的路径，以及 /etc/my.cnf0 的值。

   你还可以尝试执行一个故意慢的查询来测试日志是否生成，例如：

   SELECT SLEEP(3);

   然后检查 /etc/my.cnf1 文件中是否有这条查询记录。

慢查询日志有什么用？为什么要开启它？

从我个人的经验来看，慢查询日志简直是数据库性能优化的“金矿”。它能直接告诉你，到底哪些SQL语句是拖慢系统响应速度的罪魁祸首。没有它，你可能只能凭感觉或者通过复杂的监控系统去猜测，效率会大打折扣。

开启慢查询日志，最直接的价值就是：

1. 精准定位性能瓶颈： 它不是一个模糊的指标，而是直接记录了执行时间超过设定阈值的具体SQL语句。这就像医生直接拿到了病灶的CT片，而不是听病人描述哪里不舒服。你可以清楚地看到是哪个查询、哪个表、甚至哪个用户在消耗大量资源。
2. 指导索引优化： 结合/etc/my.cnf2参数，慢查询日志会特别指出那些没有使用索引的查询。这对于发现潜在的索引缺失或者索引设计不合理的问题非常有帮助。很多时候，一个简单的索引就能让一个慢查询瞬间提速几十甚至上百倍。
3. 洞察应用行为： 通过分析慢查询日志，你能了解到应用层哪些操作在数据库层面表现不佳。这可能意味着业务逻辑设计有问题，或者ORM框架生成的SQL不够高效。它提供了一个从数据库视角反观应用的机会。
4. 容量规划和趋势分析： 长期收集和分析慢查询日志，可以帮助你理解数据库的负载模式，预测未来的性能瓶颈，为数据库的扩容、升级或架构调整提供数据支持。

可以说，任何一个负责数据库运维或开发的工程师，如果不对慢查询日志加以利用，那几乎是错失了最重要的优化利器。

如何合理设置long_query_time参数？

/etc/my.cnf0这个参数的设置，其实是个艺术活，得根据你的业务场景和数据库负载情况来权衡。设置得太低，日志文件会迅速膨胀，里面充斥着大量你并不关心的“微慢”查询，反而增加了分析负担；设置得太高，又可能漏掉一些虽然不极致慢但累积起来影响很大的查询。

我通常会这样思考：

蓝心千询

蓝心千询是vivo推出的一个多功能AI智能助手

34

查看详情

1. 初期探索阶段： 如果是第一次开启慢查询日志，或者对系统性能状况不甚了解，我会把/etc/my.cnf0设置得相对宽松一些，比如my.ini8秒或/etc/my.cnf6秒。这样可以尽可能多地捕获到潜在的问题查询，哪怕它们只是稍微慢一点。这个阶段的主要目标是“广撒网”，收集足够的数据。
2. 业务响应时间目标： 考虑你的业务对响应时间的要求。如果你的Web应用要求接口响应在500毫秒内，那么一个执行超过200-300毫秒的数据库查询可能就已经是瓶颈了。在这种情况下，你可以把/etc/my.cnf0设置得更低，比如/etc/my.cnf8秒甚至/etc/my.cnf9秒。但要警惕，过低的阈值可能导致日志量巨大，需要配套的日志管理和分析工具。
3. 系统负载： 在高并发、高写入的系统中，即使是看起来不慢的查询，如果执行频率极高，也可能成为累积的性能问题。此时，可以尝试将/etc/my.cnf0设置得更精细，配合/etc/mysql/my.cnf1这类工具进行深入分析。
4. 迭代优化： /etc/my.cnf0不是一成不变的。你可以先设置一个值，收集一段时间的日志，分析并优化最慢的查询。当这些查询得到改善后，你可以尝试将/etc/my.cnf0调低一些，去发现新的、次一级的慢查询，这是一个持续迭代优化的过程。

一般来说，对于大多数OLTP（在线事务处理）系统，my.ini8到/etc/my.cnf6秒是一个比较稳妥的起点。如果你的系统对实时性要求极高，或者负载非常大，可以考虑/etc/my.cnf8秒甚至更低。但务必记住，阈值越低，日志量越大，对日志的处理和分析能力要求也越高。

慢查询日志文件过大怎么办？如何管理和分析日志？

慢查询日志文件膨胀是迟早会遇到的问题，特别是当你的系统运行一段时间后。如果不对日志文件进行管理，它可能会吃掉你的磁盘空间，甚至影响MySQL的正常运行。

这里有几个我常用的管理和分析策略：

1. 日志轮转（Log Rotation）： 这是最基本也是最重要的管理方式。在Linux系统上，/etc/mysql/my.cnf7工具就是为此而生。你可以配置/etc/mysql/my.cnf7，让它定期（例如每天或每周）对慢查询日志文件进行归档、压缩和删除旧文件。

   一个简单的/etc/mysql/my.cnf7配置示例（可以放在my.ini0）：

   /var/log/mysql/mysql-slow.log {     daily               # 每天轮转     rotate 7            # 保留7个归档文件     missingok           # 如果日志文件不存在，不报错     notifempty          # 如果日志文件为空，不轮转     compress            # 压缩归档文件     delaycompress       # 延迟压缩，与旧文件一起压缩     create 640 mysql mysql # 以指定权限和用户组创建新文件     sharedscripts       # 共享脚本     postrotate          # 轮转后执行的脚本         # 告诉MySQL重新打开日志文件，避免重启服务         if test -x /usr/bin/mysqladmin &&             /usr/bin/mysqladmin ping &>/dev/null         then            /usr/bin/mysqladmin --defaults-file=/etc/my.cnf flush-logs         fi     endscript }

   my.ini1命令非常关键，它会告诉MySQL关闭当前的慢查询日志文件，并重新打开一个新的文件，这样/etc/mysql/my.cnf7就可以安全地处理旧文件了。

2. 使用my.ini3工具进行初步分析： MySQL自带的my.ini3工具是分析慢查询日志的利器。它能帮你对日志进行聚合和排序，找出出现频率最高、总耗时最长、平均耗时最长的慢查询。

   一些常用示例：

   • 按访问次数排序，显示前10条：my.ini5 (my.ini6 按计数排序，my.ini7 显示前10条)
   • 按总耗时排序，显示前10条：my.ini8 (my.ini9 按时间排序)
   • 按平均耗时排序，显示前10条：SHOW VARIABLES LIKE '%datadir%';0 (SHOW VARIABLES LIKE '%datadir%';1 按平均时间排序)
   • 只分析包含特定字符串的查询：SHOW VARIABLES LIKE '%datadir%';2

   my.ini3的输出会将查询中的具体参数替换为SHOW VARIABLES LIKE '%datadir%';4或SHOW VARIABLES LIKE '%datadir%';5，这样方便你看到查询的模式，而不是具体的某一次执行。

3. 使用/etc/mysql/my.cnf1进行深度分析： 对于更复杂的分析需求，Percona Toolkit中的/etc/mysql/my.cnf1是一个功能更强大的工具。它能生成非常详细的慢查询报告，包括每个查询的执行次数、总耗时、平均耗时、锁时间、发送给客户端的行数等，甚至还能给出查询的执行计划建议。

   示例： SHOW VARIABLES LIKE '%datadir%';8

   /etc/mysql/my.cnf1的报告非常详细，能够帮助你从多个维度深入理解慢查询的性能特征。这是我个人在做数据库性能调优时，几乎每次都会用到的工具。

4. 自定义脚本或监控系统集成： 对于大型或复杂的系统，你可能需要开发自定义脚本来解析日志，或者将其集成到现有的监控系统（如Prometheus + Grafana）中。这样可以实现实时的慢查询告警，或者将慢查询数据可视化，以便更好地跟踪趋势。

总的来说，慢查询日志的管理和分析是一个持续的过程。它需要你定期关注、分析，并根据分析结果进行数据库和应用层的优化。这不仅仅是技术活，更是一种对系统性能的持续追求。