慢查询优化需从执行计划、索引设计、sql写法等入手。首先开启慢查询日志,使用EXPLaiN分析执行计划,关注type、key、rows和Extra字段;合理创建复合索引并遵循最左前缀原则,避免在索引列上使用函数;优化SQL写法,避免select *、大OFFSET分页,JOIN字段需有索引且类型一致;可拆分大表、使用覆盖索引;应用层缓存高频结果,定期ANALYZE table更新统计信息;通过pt-query-digest等工具持续监控与迭代优化,逐条分析验证,提升系统响应速度。

慢查询是影响 mysql 性能的常见问题,优化这类 SQL 语句需要从执行计划、索引设计、表结构和查询写法等多方面入手。关键在于找出瓶颈并针对性改进,而不是盲目添加索引或重写语句。
分析慢查询来源
开启慢查询日志是第一步,确保在 my.cnf 中配置以下参数:
log-slow-queries = /var/log/mysql/slow.log
long_query_time = 1
log-queries-not-using-indexes
使用 mysqldumpslow 或 pt-query-digest 分析日志,找出执行时间长、调用频繁或扫描行数多的 SQL。
对目标 SQL 使用 EXPLAIN 查看执行计划,重点关注:
- type:尽量避免 ALL(全表扫描),最好为 index 或 ref
- key:确认是否使用了预期索引
- rows:预估扫描行数,越少越好
- Extra:避免出现 Using filesort、Using temporary
合理创建和使用索引
索引是提升查询速度最有效的手段,但需注意以下原则:
- 为 WHERE、ORDER BY 和 GROUP BY 涉及的列建立索引
- 复合索引遵循最左前缀原则,顺序很重要
- 避免在索引列上使用函数或表达式,如 WHERE YEAR(create_time) = 2023
- 选择区分度高的列作为索引,例如用户ID优于性别字段
- 定期清理冗余或未使用的索引,减少维护开销
例如,对于查询:
SELECT * FROM orders WHERE user_id = 123 AND status = ‘paid’ ORDER BY create_time DESC;
建议创建复合索引:(user_id, status, create_time),可覆盖查询条件和排序。
优化SQL写法和表结构
不合理的 SQL 写法会绕过索引或增加计算负担:
- 避免 SELECT *,只查询需要的字段,减少数据传输量
- 用 IN 替代 OR(在某些情况下更高效)
- 分页时避免 OFFSET 过大,可记录上次位置改用 WHERE id > ? LIMIT ?
- 大表 JOIN 要确保关联字段有索引,且类型一致(如都为 int)
- 考虑垂直或水平拆分大表,减少单表数据量
适当使用覆盖索引(Covering Index),让查询只需访问索引即可完成,无需回表。
利用缓存与统计信息
MySQL 查询缓存虽在 8.0 被移除,但应用层可使用 redis 或 memcached 缓存高频结果。
更新表的统计信息有助于优化器选择更优执行计划:
ANALYZE TABLE table_name;
对于复杂查询,可尝试重写为子查询或临时表分步处理,避免一次性大运算。
基本上就这些。关键是持续监控、逐条分析、小步验证。优化一条慢 SQL 往往能显著提升系统响应速度。


