开启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：指定慢查询日志的输出方式。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。
-
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/索引 -> 观察日志 -> 再次优化。这是一个持续改进的过程，没有一劳永逸的解决方案。
