为什么慢查询排查需要固定流程

数据库响应变慢往往由多因素叠加引起，如果没有一个清晰的排查框架，容易陷入盲目加索引或调整参数的循环。建议从现象到根因逐步缩小范围，优先处理对业务影响高频且耗时严重的语句，避免一次性大量变更带来新风险。

第一步：启用并分析慢查询日志

慢查询日志是排查的起点。需确认 slow_query_log 已开启，并合理设置 long_query_time（例如 1 秒）。收集一段时间（如业务高峰段）的日志后，使用 mysqldumpslow 或 pt-query-digest 等工具汇总。按执行次数 × 单次耗时的积排序，优先处理总体开销最大的语句，而非仅限于单次最慢的查询。

第二步：使用 EXPLAIN 解读执行计划

对筛选出的慢查询执行 EXPLAIN 或 EXPLAIN FORMAT=JSON，核心关注以下字段：

  • type：连接类型。若出现 ALL，说明发生全表扫描，通常需要优化。理想情况应达到 range、ref 或 const。

  • key：实际使用的索引。若为 NULL，表示未使用索引；若与预期不符，需检查索引定义与查询条件是否匹配。

  • rows：优化器估算的扫描行数。该值应尽量接近实际返回行数，若远大于返回行数，说明扫描了大量无用数据。

  • Extra：额外信息。重点关注 Using filesort、Using temporary，它们可能意味着额外的排序或临时表开销。

第三步：定位常见索引失效场景

结合执行计划和 SQL 写法，常见问题包括：

  • 条件字段缺少索引，或复合索引的列顺序不符合最左前缀规则。

  • 隐式类型转换：如字符串列与数值比较，或字符集不一致导致索引失效。

  • 对索引列使用函数或运算，如 WHERE DATE(create_time) = '2025-01-01' 会使列上的索引无效。

  • 深分页问题：如 LIMIT 100000,10 会导致大量无效行扫描，可改用延迟关联或记录游标的方式优化。

  • 统计信息不准确：可通过 ANALYZE TABLE 更新，帮助优化器选择更优计划。

第四步：验证优化效果并兼顾写入代价

添加或调整索引后，再次执行 EXPLAIN 并实际运行查询，对比执行时间与扫描行数的变化。同时需要关注索引对 INSERT/UPDATE/DELETE 性能的影响，因为索引并非越多越好。对于读多写少的业务可适当增加索引，写密集型业务则需谨慎权衡。

业务引导与长期维护建议

建议将慢查询排查纳入日常巡检，定期查看慢查询日志趋势。对于线上变更，先在测试环境充分验证，并尽量在低峰期操作。可在业务代码中接入 APM 工具追踪数据库调用，结合 SQL 审计平台统一管理，帮助团队更快定位问题。