全表扫描860万行！我用三次Explain对比把查询优化了500倍
数据库性能优化实战：一条慢查询引发的Explain深度对比与SQL调优全过程
去年双十一大促前夜，监控系统突然告警：订单查询接口响应时间从200ms飙升到了8秒多。运维群里炸开了锅，DBA连夜排查，发现一条看起来"很简单"的订单列表查询，竟然在大数据量下把数据库拖垮了。这条SQL写了三年没人动过，数据量从十万涨到了八百万，性能却从来没人真正关注。这个真实案例让我深刻意识到：SQL优化不是等出了问题才去补救，而是要养成用Explain对比分析的习惯。今天这篇文章，我就用这个真实案例，从头到尾演示一遍Explain对比分析的完整流程，把踩过的坑、总结的经验全部写出来。
一、问题定位：那条拖垮数据库的"简单"SQL
先看问题SQL，这是一个非常典型的订单列表查询，业务代码里写了三年，谁都觉得没问题：
sql
SELECT o.order_id, o.user_id, o.total_amount, o.status,
u.nickname, u.avatar
FROM orders o
LEFT JOIN users u ON o.user_id = u.user_id
WHERE o.status IN (1, 2, 3)
AND o.create_time >= '2024-01-01 00:00:00'
ORDER BY o.create_time DESC
LIMIT 20;
表结构如下：
表名 数据量 主要字段 现有索引
orders 860万 order_id(PK), user_id, status, create_time, total_amount PRIMARY(order_id), idx_user_id(user_id), idx_create_time(create_time)
users 120万 user_id(PK), nickname, avatar PRIMARY(user_id)
这条SQL在测试环境数据量只有几万条的时候，跑得飞快，没人在意。但生产环境数据量一上来，问题就暴露了。当时DBA跑了一把Explain，结果让人倒吸一口凉气：
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE o ALL idx_user_id,idx_create_time NULL NULL NULL 8632145 Using where; Using filesort
1 SIMPLE u eq_ref PRIMARY PRIMARY 8 db.o.user_id 1 NULL
☆ type列显示ALL，意味着orders表做了全表扫描，扫描了863万行数据。☆ Extra列出现了Using filesort，说明ORDER BY没有走索引，额外做了文件排
