mysql慢查询阈值的设置是通过配置long_query_time变量并开启慢查询日志实现的。1. 临时设置可在mysql客户端执行：set global long_query_time = 1; set global slow_query_log = on; 2. 永久设置需修改my.cnf或my.ini文件，添加long_query_time、slow_query_log及相关参数，并重启mysql服务生效；3. 验证设置可通过show variables命令检查配置、确认日志路径权限及手动执行select sleep(3)测试日志记录；4. 合理阈值取决于业务sla、服务器性能和日志处理能力，建议从1秒起步并结合pt-query-digest等工具分析日志后动态调整；5. 除long_query_time外，还应启用log_queries_not_using_indexes以记录未使用索引的查询，设置min_examined_row_limit过滤低扫描行数的语句，并根据需求选择log_output输出方式（file或table），最终通过explain和pt-query-digest深入分析并优化sql性能瓶颈。
MySQL慢查询阈值的设置，说白了，就是给你的数据库定一个“慢”的标准。这个标准一旦定下来，那些执行时间超过你设定的sql语句就会被记录下来，成为你优化数据库性能的重要线索。它就像一个高效的哨兵，帮你精准地找出那些拖慢系统响应速度的“害群之马”，让你能有的放矢地进行优化，而不是大海捞针。
解决方案
要精准捕获低效SQL语句，核心在于合理配置MySQL的long_query_time变量，并确保慢查询日志功能是开启的。
首先，你需要决定一个“慢”的阈值。这个值通常以秒为单位。例如，如果你认为任何执行时间超过1秒的查询都算慢，那么就设为1。
有两种主要方式来设置这个值：
-
临时设置（运行时生效，重启后失效）： 你可以在MySQL客户端里执行：
SET GLOBAL long_query_time = 1; -- 设置慢查询阈值为1秒 SET GLOBAL slow_query_log = ON; -- 开启慢查询日志
这种方式适合快速测试或临时调整。
-
永久设置（修改配置文件，推荐生产环境使用）： 找到你的MySQL配置文件，通常是my.cnf或my.ini。在[mysqld]段下添加或修改以下行：
[mysqld] long_query_time = 1 # 慢查询阈值，单位秒 slow_query_log = 1 # 开启慢查询日志，1表示ON，0表示OFF slow_query_log_file = /var/log/mysql/mysql-slow.log # 慢查询日志文件路径，请根据实际情况修改 log_queries_not_using_indexes = ON # 记录没有使用索引的查询，即使它们执行很快 min_examined_row_limit = 1000 # 只有扫描行数超过这个值的查询才会被记录（结合long_query_time）
修改配置文件后，你必须重启MySQL服务才能让这些更改生效。例如，在linux上可能是sudo systemctl restart mysql或sudo service mysql restart。
设置好之后，MySQL就会开始将那些执行时间超过long_query_time阈值的SQL语句记录到你指定的日志文件中。
MySQL慢查询日志没记录？如何验证设置是否生效？
这确实是个常见的问题，我以前也遇到过。有时候你明明觉得设置对了，但日志文件就是空空如也，或者压根没生成。别急，我们一步步排查。
首先，最直接的办法就是去看看当前的MySQL配置：
SHOW VARIABLES LIKE '%slow_query%'; SHOW VARIABLES LIKE 'long_query_time';
执行这两条SQL，检查slow_query_log是否是ON，long_query_time的值是不是你期望的。同时，slow_query_log_file会告诉你日志文件的具体路径。
接下来，确保日志文件路径是可写的。如果MySQL进程没有权限写入到你指定的路径，那日志肯定不会生成。你可以手动创建一个空文件，然后给MySQL用户赋予写入权限，比如：
sudo touch /var/log/mysql/mysql-slow.log sudo chown mysql:mysql /var/log/mysql/mysql-slow.log
（这里的mysql:mysql是MySQL运行的用户和组，请根据你的系统实际情况调整）。
还有一种情况，就是你的long_query_time设置得太高了，导致几乎没有查询能达到那个“慢”的标准。或者，你的应用根本就没有那么慢的查询（虽然这在真实世界里比较少见）。为了验证，你可以手动制造一个“慢查询”：
SELECT SLEEP(3); -- 假设你的long_query_time设为1秒
执行这条SQL，如果一切设置正确，并且日志文件权限没问题，那么SELECT SLEEP(3)这条语句就应该被记录到慢查询日志里。如果还是没有，那么很可能是MySQL服务没有正确读取到配置文件，或者它启动时加载了其他的配置文件。这需要你检查MySQL的启动参数和日志，看看它到底加载了哪个my.cnf。
MySQL慢查询阈值设多少合适？如何平衡性能与日志量？
这问题问到点子上了，没有一个“放之四海而皆准”的答案。我个人觉得，这个阈值设置，更多的是一种艺术和经验的结合，而不是简单的数学公式。
通常，我会建议从一个相对保守的值开始，比如1秒。为什么是1秒？因为对于大多数在线业务来说，1秒的用户等待时间已经能明显感知到延迟了。如果一个查询需要1秒才能返回，那它多半值得我们去关注。
但这个1秒也不是绝对的。你需要考虑几个因素：
- 你的业务SLA（服务等级协议）和用户体验预期：如果你的应用要求极高的实时性，比如金融交易系统，那么0.1秒甚至更低可能就是你的“慢”标准。而对于一些后台批处理任务，10秒甚至30秒可能都算正常。
- 服务器的硬件配置和负载情况：一台配置很低的服务器，可能很多查询都会超过1秒。这时候如果把阈值设为1秒，日志量可能会爆炸式增长，反而成了负担。反之，如果服务器性能强劲，那么0.5秒可能就是一个很好的起点。
- 日志存储空间和分析能力：慢查询日志可能会非常大，特别是当你把阈值设得很低的时候。你需要确保有足够的磁盘空间来存储这些日志，并且有能力（比如使用pt-query-digest这样的工具）来分析它们。如果日志量太大，你根本没时间去分析，那这个日志也就失去了意义。
我的经验是，这是一个迭代优化的过程：
- 初期设定：先设一个相对通用的值（如1秒），观察一段时间。
- 分析日志：用pt-query-digest工具对日志进行分析，看看哪些查询是主要的瓶颈，它们的平均执行时间是多少。
- 调整阈值：根据分析结果，如果你发现很多“正常”的查询也被记录进来了，或者日志量实在太大，可以适当提高阈值。反之，如果你觉得很多有问题的查询被漏掉了，可以适当降低阈值。
- 重复：这是一个持续的过程，随着业务发展和数据量的增长，你需要周期性地回顾和调整这个阈值。
过度追求“完美”的阈值是没有意义的，关键在于它能帮助你有效地识别和解决问题。
除了long_query_time，还有哪些MySQL慢查询优化利器？
确实，long_query_time只是个开始，它帮你圈定了“慢”的范围。但要真正理解和优化，还需要结合其他一些配置和工具。
首先，我个人非常推荐开启log_queries_not_using_indexes。这个变量的作用是记录那些没有使用索引的查询，即使它们的执行时间可能很短。为什么它重要？因为全表扫描（没有使用索引）是数据库性能的头号杀手。一个全表扫描的查询，在数据量小的时候可能很快，但在数据量增长后，它会指数级地变慢。提前发现并优化这些“潜在的慢查询”，远比等它们真正变慢了再去处理要高效得多。
接着是min_examined_row_limit。这个参数和long_query_time是协同工作的。它表示只有当查询扫描的行数超过这个值时，才会被记录到慢查询日志中。举个例子，你可能有一个查询，它只扫描了10行数据，但由于网络延迟或其他瞬时原因，它执行了2秒（超过了你的long_query_time）。这种查询可能并不是真正的性能问题。通过设置min_examined_row_limit，比如设置为1000，你就可以过滤掉那些扫描行数很少但偶尔“慢”的查询，让慢查询日志更聚焦于那些真正需要优化的复杂查询。
关于日志的输出形式，log_output这个变量也值得提一下。它决定了慢查询日志是写入文件（FILE）还是写入数据库表（TABLE）。默认是FILE，这对于大多数情况来说是最好的选择，因为它对数据库本身的性能影响最小。但如果你想通过SQL直接查询慢查询日志，或者需要更灵活地管理日志数据，可以考虑设置为TABLE。不过，这会增加数据库的I/O负载，需要谨慎评估。
最后，光有日志还不够，你得有分析日志的工具。mysqldumpslow是MySQL自带的一个命令行工具，虽然功能相对简单，但也能帮你对慢查询日志进行初步的统计和排序。真正强大的分析工具是Percona Toolkit里的pt-query-digest。它能对慢查询日志进行深度分析，包括聚合相似的查询、计算它们的总执行时间、平均执行时间、扫描行数等，并生成非常详细的报告。这对于找出最耗时的查询模式，以及评估优化效果，简直是神器。
当然，除了这些配置和工具，最终还是要回到SQL本身。当你找到那些慢查询后，使用EXPLAIN和EXPLAIN ANALYZE（MySQL 8.0+）来深入分析查询的执行计划，理解为什么它会慢，然后针对性地添加索引、重写SQL、优化表结构，才是解决问题的根本之道。
