427 字
2 分钟
MySQL 慢查询如何定位和优化
慢查询排查先确认问题范围:SQL 指纹、调用频率、P95/P99 延迟、扫描行数、并发和影响的实例。开启并配置慢查询日志可找到超过阈值的语句;阈值过高会漏掉高频的小慢查询,过低则可能产生大量日志。生产环境启用前应评估日志量、敏感字段和磁盘空间。
对代表性 SQL 查看 EXPLAIN;必要时在安全环境使用 EXPLAIN ANALYZE。逐项核查过滤条件和联合索引、估算与实际行数偏差、回表量、排序/临时表、连接顺序、锁等待和 I/O。慢不一定是缺索引:可能是返回数据太多、锁等待、热点页、网络传输或执行计划随参数变化。应用侧还要检查 N+1 查询和连接池排队。
优化后用相同参数范围、数据规模和并发复测延迟及资源消耗。新索引可降低读成本,却增加写放大、磁盘占用和维护;改写 SQL 也要验证结果一致。不要在生产直接执行高风险 ANALYZE TABLE、大范围 DDL 或 EXPLAIN ANALYZE,应按平台操作规范评估。
追问
- 慢日志没有记录但接口慢,下一步看什么? 检查锁等待、连接池排队、网络、应用耗时分布和 Performance Schema 等运行指标。
- 发现全表扫描就加索引吗? 先核对表规模、过滤率和访问频率,优化器可能判断全扫成本更低。
- 索引上线后如何确认有效? 对照执行计划、实际扫描行数、延迟和写入/空间成本,并监控真实业务负载。
目录