MySQL怎么优化慢查询日志 MySQL索引优化与参数调整详解

进阶一点，使用 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 这类管理语句即使执行很慢，也不会出现在常规的慢查询日志中。然而，这类语句虽然执行频率不高，可一旦变慢，影响的是整个表的可用性。如果你在日志里始终找不到这类“元凶”，记得检查并打开这个开关。