MySQL订单表索引优化实战：从慢查询到毫秒响应

1. 订单表索引优化实战：从慢查询到毫秒响应的完整解决方案

最近在电商系统性能调优过程中，遇到一个典型的订单查询性能问题：当用户历史订单量超过50万条时，"查询我的订单"接口响应时间从平均200ms骤增至8秒以上。通过分析发现是订单表索引设计不合理导致的慢SQL问题。本文将完整还原从问题定位到最终优化的全过程，分享订单表索引设计的核心方法论。

2. 问题定位与慢SQL分析

2.1 原始表结构与查询模式

订单表原始结构如下（简化版）：

sql复制CREATE TABLE `orders` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL,
  `order_no` varchar(32) NOT NULL,
  `status` tinyint(4) NOT NULL COMMENT '1待支付 2已支付 3已发货 4已完成',
  `total_amount` decimal(10,2) NOT NULL,
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_order_no` (`order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

高频查询场景包括：

1. 用户中心分页查询个人订单（按时间倒序）

sql复制SELECT * FROM orders WHERE user_id = ? ORDER BY create_time DESC LIMIT 0,10

2. 后台按订单状态筛选

sql复制SELECT * FROM orders WHERE status = ? AND create_time BETWEEN ? AND ? 

2.2 性能瓶颈诊断

通过EXPLAIN分析发现两个严重问题：

1. 用户订单查询走了全表扫描（type=ALL）
2. 状态筛选查询虽然使用了status索引，但需要回表5万+次

关键发现：在没有user_id索引的情况下，即使查询条件包含user_