慢查询优化需从执行计划、索引设计、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.loglong_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 往往能显著提升系统响应速度。
