MySQL慢查询日志优化技巧 索引设计与参数调整全面指南
如何开启慢查询日志才不拖垮磁盘与性能
直接启用 log_queries_not_using_indexes = ON，通常是新手数据库管理员最容易掉入的陷阱。这个操作表面上一劳永逸，实际隐患极大——它会将每一条未走索引的SQL语句，哪怕仅扫描一行、耗时不足一毫秒，都完整写入日志。结果可想而知，慢查询日志可能在几小时内急剧膨胀，迅速占满磁盘空间。因此，在生产环境下，这个参数必须与 min_examined_row_limit 配合使用，设置一个合理的扫描行数下限。
那么，临时排查问题时，如何配置才算稳妥呢？可以参考下面这套组合配置：
SET GLOBAL slow_query_log = 'ON'SET GLOBAL long_query_time = 1（对核心业务，甚至可以设为0.5以捕获更细微的慢查询）SET GLOBAL min_examined_row_limit = 1000（仅记录扫描行数超过1000的语句，有效过滤噪声）SET GLOBAL log_queries_not_using_indexes = 'OFF'（关键一步：先不要开启它！）
如需永久生效，记得将配置写入 /etc/my.cnf 的 [mysqld] 配置段，然后重启数据库服务。这里有个细节需要注意：修改后务必执行 SHOW VARIABLES LIKE '%slow%' 确认新值已成功加载。尤其是MySQL 8.0及以上版本，变量命名风格可能改用下划线，例如 slow_query_log，而非旧版的 slow-query-log。
EXPLAIN 看懂这三列就能抓住慢查询根源
慢查询日志中的 Query_time 和 Rows_examined 只能告诉你“查询变慢了”，但无法揭示“为什么变慢”。真正的诊断工具是 EXPLAIN 命令。面对它的输出结果，不必被所有字段吓到，集中精力盯紧以下三列，就能锁定问题核心：
type：这是访问类型。如果出现ALL，基本等于宣告全表扫描，索引很可能没有起作用。理想的状态应该是range（范围扫描）或ref（等值查询）。key：这里显示实际使用的索引名称。如果这一列是NULL，可不是好消息，它意味着MySQL优化器最终没有选择任何索引。背后原因可能是字段类型不匹配、查询条件中使用了函数、或未满足联合索引的“最左前缀”原则。rows：这是优化器预估需要扫描的行数。如果这个数值远大于查询实际返回的行数（比如一个SELECT COUNT(*)只返回1行，但rows却显示500000），就需要高度警惕了。这通常指向索引失效，或者表的统计信息已经过时，误导了优化器。
进阶一点，使用 EXPLAIN FORMAT=JSON 还能看到一个叫 filtered 的字段。它表示经过条件过滤后，剩余行数的预估百分比。如果这个值低于10%，就是一个明确的警告信号——说明当前索引的区分度太低，或者WHERE条件的选择性太差，需要重新审视索引设计。
联合索引怎么建才不白费功夫
给表添加联合索引，可不是把字段随意堆叠就完事了。顺序建错，索引就等于形同虚设，查询时依旧慢如蜗牛。
举个例子，假设有一个常见查询：WHERE status = 'paid' AND create_time > '2023-01-01' ORDER BY amount DESC。索引应该怎么建？
- 错误示范：
INDEX(create_time, status)。因为create_time是范围查询（>），根据最左前缀原则，它后面的status字段将无法被用于索引过滤，实际上就失效了。 - 正确做法：
INDEX(status, create_time)。将等值查询的字段status放在前面，先精准定位到‘paid’状态的行，然后再对create_time进行范围扫描，这完全符合索引的最左前缀匹配规则。 - 更优方案：如果查询只需要返回
id, status, amount这几个字段，那么可以考虑INDEX(status, create_time, amount)。这就是“覆盖索引”的妙用——所有需要的数据都在索引树中，无需回表查询数据行，性能提升立竿见影。
最后，有两个原则务必牢记：一是避免为使用 LIKE '%xxx' 这种前导通配符的字段单独建立索引，它用不上；二是不要在WHERE条件中对索引字段使用函数，比如 WHERE DATE(create_time) = '2023-01-01'，这会让索引瞬间失效，强制进行全表扫描。
哪些参数调整后反而让慢查询更难定位
很多数据库管理员一上来就热衷于调整 innodb_buffer_pool_size 或调低 long_query_time，却忽略了一些本身就会干扰诊断过程的参数设置。
log_output = TABLE：这个设置看起来很方便，慢查询直接记录在mysql.slow_log系统表里，随手就能查。但在高并发场景下，向这个表写入日志本身会产生锁和I/O开销，可能反过来拖慢正常的业务查询。相比之下，使用文件模式（log_output = FILE）通常更为轻量和安全。long_query_time = 0：在测试环境用于捕捉所有查询无可厚非。但如果上线后忘记调整回来，海量的日志会瞬间淹没磁盘，甚至连mysqldumpslow这样的日志分析工具都可能因为解析过大的文件而卡住。slow_query_log_file路径：如果把慢查询日志文件放在系统盘，或者与数据库的数据目录（datadir）放在同一块物理磁盘上，就会产生激烈的I/O竞争。这可能导致慢查询记录出现延迟，甚至在极端情况下丢失最后几条关键的日志信息。
还有一个容易被忽略的参数是 log_slow_admin_statements。它默认是关闭的，因此像 ALTER TABLE、ANALYZE TABLE 这类管理语句即使执行很慢，也不会出现在常规的慢查询日志中。然而，这类语句虽然执行频率不高，可一旦变慢，影响的是整个表的可用性。如果你在日志里始终找不到这类“元凶”，记得检查并打开这个开关。
