MySQL 索引优化总结

数据量从几万增长到几百万后，慢查询通常不是“数据库不行”，而是索引设计与 SQL 写法没有贴合业务访问路径。下面是一次虚拟电商订单表优化记录。

1. 问题场景

高频接口是“按用户 + 时间范围 + 状态查询订单列表”，高峰期接口平均耗时 420ms，偶发超过 1s。SQL 大致如下：

SELECT id, order_no, amount, status, created_at
FROM t_order
WHERE user_id = ?
  AND status = ?
  AND created_at BETWEEN ? AND ?
ORDER BY created_at DESC
LIMIT 20;

2. 索引设计思路

• 根据 where 条件与排序字段设计联合索引，减少回表与排序开销
• 遵循最左前缀原则，优先放筛选区分度高的字段
• 尽量让查询字段被索引覆盖，降低随机 I/O
• 避免重复索引与无效索引，控制写入成本

针对该场景，最终使用联合索引：(user_id, status, created_at)。

3. EXPLAIN 观察重点

• type：至少要达到 range 或更优
• key：确认命中目标索引，而非走错索引
• rows：扫描行数是否明显下降
• Extra：尽量避免 Using filesort 和 Using temporary

4. 常见踩坑

• 在索引字段上使用函数，如 DATE(created_at)，导致索引失效
• 隐式类型转换（字符串查数字）引发全表扫描
• 把低区分度字段放在联合索引最左侧
• 一次性建太多索引，查询快了但写入明显变慢

5. 优化结果（假数据）

优化后平均耗时从 420ms 降到 38ms，P95 从 1.1s 降到 120ms，数据库 CPU 峰值下降约 23%。说明索引策略与访问模式基本匹配。

← 返回首页