MySQL索引优化案例分析：如何提升查询性能

MySQL索引优化是数据库性能调优中最常见的需求，多数查询性能问题都可以通过合理的索引设计与调整解决。下面通过一个电商订单查询的实际案例，展示完整的索引优化过程。

案例背景

某电商平台的订单表order_info存储了近千万条订单数据，表结构简化如下：

CREATE TABLE `order_info` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL COMMENT '用户ID',
  `order_status` tinyint(4) NOT NULL COMMENT '订单状态 1待支付 2已支付 3已发货 4已完成',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `pay_time` datetime DEFAULT NULL COMMENT '支付时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

业务侧有一个高频查询需求：查询某个用户近30天的已支付订单，按创建时间倒序排列，SQL语句如下：

SELECT * FROM order_info 
WHERE user_id = 10001 
  AND order_status = 2 
  AND create_time >= '2024-01-01 00:00:00' 
  AND create_time <= '2024-01-31 23:59:59' 
ORDER BY create_time DESC 
LIMIT 20;

初始执行计划分析

先使用explain命令查看该查询的执行计划，判断当前索引使用情况：

EXPLAIN
SELECT * FROM order_info 
WHERE user_id = 10001 
  AND order_status = 2 
  AND create_time >= '2024-01-01 00:00:00' 
  AND create_time <= '2024-01-31 23:59:59' 
ORDER BY create_time DESC 
LIMIT 20;

执行结果如下：

从结果可以看出，当前查询走的是全表扫描（type为ALL），扫描行数接近百万，同时存在Using filesort排序操作，查询耗时超过2秒，性能完全不符合业务要求。

索引优化过程

第一步：设计联合索引

查询条件的等值条件有user_id和order_status，范围条件有create_time，根据联合索引最左匹配原则，范围条件需要放在联合索引的最后，因此设计联合索引idx_user_status_time：

ALTER TABLE order_info ADD INDEX idx_user_status_time (user_id, order_status, create_time);

第二步：再次分析执行计划

添加索引后重新执行explain，结果如下：

此时查询类型变为range范围扫描，扫描行数下降到123行，Using filesort也消失了，因为联合索引的create_time字段已经有序，排序可以直接利用索引顺序。查询耗时下降到50毫秒左右，性能提升明显。

第三步：优化查询字段实现索引覆盖

业务侧实际只需要订单的id、用户ID、订单状态、创建时间、支付时间这几个字段，不需要全部字段，因此可以调整查询字段，实现索引覆盖，避免回表操作：

SELECT id, user_id, order_status, create_time, pay_time 
FROM order_info 
WHERE user_id = 10001 
  AND order_status = 2 
  AND create_time >= '2024-01-01 00:00:00' 
  AND create_time <= '2024-01-31 23:59:59' 
ORDER BY create_time DESC 
LIMIT 20;

由于pay_time不在联合索引中，需要把pay_time也加入索引实现全覆盖：

ALTER TABLE order_info DROP INDEX idx_user_status_time;
ALTER TABLE order_info ADD INDEX idx_user_status_time_pay (user_id, order_status, create_time, pay_time);

调整后执行计划Extra字段显示Using index，表示使用了索引覆盖，查询耗时进一步下降到10毫秒以内。

优化总结

本次案例的优化核心思路如下：

• 优先根据查询条件的等值字段和范围字段设计联合索引，遵循最左匹配原则，范围条件放在索引最后
• 利用explain执行计划分析查询瓶颈，判断是全表扫描、索引失效还是排序效率低等问题
• 尽量使用索引覆盖减少回表操作，只查询需要的字段，避免SELECT *
• 定期清理冗余索引和无用索引，避免索引过多影响写入性能

实际优化中还需要结合具体业务场景调整，比如如果查询条件的字段顺序不固定，可能需要设计多个联合索引适配不同查询场景，平衡查询性能和索引维护成本。

MySQL索引优化查询性能explain修改时间：2026-06-12 11:27:17