MySQL查询优化实战：从索引原理到分页陷阱

1. 为什么需要关注MySQL查询优化

记得刚入行那会儿，我接手过一个电商后台系统，某个商品列表页的加载时间竟然要8秒多。通过EXPLAIN分析发现，一条看似简单的SELECT语句全表扫描了200万条记录。那次经历让我深刻认识到：数据库查询优化不是"高级技巧"，而是每个开发者必须掌握的基本功。

查询优化的本质是在有限的硬件资源下，用更少的IO和CPU时间获取相同的数据。好的优化能让吞吐量提升数倍，差的查询则可能拖垮整个系统。特别是在用户量增长、数据量膨胀时，那些在测试环境跑得飞快的SQL，在生产环境可能瞬间成为性能瓶颈。

2. 基础优化策略与原理剖析

2.1 索引的正确打开方式

上周帮同事排查一个"订单查询超时"问题，发现他们在user_id和create_time字段上分别建了单列索引，但查询条件是WHERE user_id=? AND create_time>?。这种场景下，MySQL只能选择一个索引（最终选了user_id），导致仍然扫描了大量记录。解决方案很简单——建立联合索引(user_id,create_time)，查询速度立即从2.3秒降到23毫秒。

联合索引的字段顺序很重要，要遵循"最左前缀原则"。比如索引(a,b,c)可以用于：

• WHERE a=?
• WHERE a=? AND b=?
• WHERE a=? AND b=? AND c=?
  但不能用于：
• WHERE b=?
• WHERE c=?
• WHERE b=? AND c=?

2.2 EXPLAIN执行计划详解

执行计划是优化SQL的"X光片"。重点看这几个字段：

• type：从最优到最差依次是 system > const > eq_ref > ref > range > index > ALL
• key：实际使用的索引
• rows：预估扫描行数
• Extra：常见重要值：
  • Using filesort：需要额外排序
  • Using temporary：使用了临时表
  • Using index：覆盖索引扫描

经验：如果type是ALL或rows超过1000，就需要重点优化了

3. 高级优化技巧实战

3.1 分页查询