ORDER BY在JOIN后变慢是因为连接生成的临时结果集无法复用单表索引，导致Using filesort；需通过复合索引（如(user_id, created_at)）、提前过滤或游标分页优化。
为什么ORDER BY在JOIN后变慢了
因为数据库通常无法复用单表索引完成连接后的排序。比如users有created_at索引，orders有user_id索引，但JOIN users ON orders.user_id = users.id ORDER BY orders.created_at仍可能触发Using filesort——连接结果集是动态生成的，原有索引不覆盖这个组合结构。
常见错误现象：EXPLAIN里出现Using temporary; Using filesort，哪怕只查10条也延迟明显。
- 先JOIN再ORDER BY，等价于对临时结果集排序，数据量一过万就抖
- 如果
WHERE条件没命中索引，排序前还要全表扫描连接，雪上加霜 - MySQL 8.0+ 支持
LATERAL或物化CTE，但默认不自动启用，得手动改写
用覆盖索引把排序“提前”到连接前
核心思路：让排序字段和JOIN字段一起落在同一个复合索引里，使优化器能在连接过程中直接按序读取数据，避免事后排序。
例如要查“每个用户最新一笔订单”，写法：SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE o.id IN (SELECT MAX(id) FROM orders GROUP BY user_id) ORDER BY o.created_at DESC——这仍然慢。换成索引驱动：
给orders建索引：CREATE INDEX idx_user_created_id ON orders (user_id, created_at DESC, id)；再配合子查询或ROW_NUMBER()（MySQL 8.0+）：
SELECT u.name, o.amount
FROM users u
INNER JOIN (
SELECT user_id, amount, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) rn
FROM orders
) o ON u.id = o.user_id AND o.rn = 1
这样orders扫描时就能按user_id + created_at顺序走索引，ROW_NUMBER()计算开销小，且不依赖临时表。
- 索引字段顺序很重要：
(user_id, created_at)有效，(created_at, user_id)对JOIN无帮助 -
DESC在索引定义中仅影响排序方向，不影响JOIN效率，但能匹配ORDER BY ... DESC避免反向扫描 - 如果
orders表有高频INSERT，created_at DESC索引可能加剧页分裂，需权衡
用WHERE限制连接范围，比ORDER BY更早生效
排序慢的根因常是连接结果集太大。与其让数据库排序10万行，不如让它只连100行——把过滤逻辑尽量往前压。
典型场景：后台分页查“最近7天订单+用户信息”，却写成JOIN ... ORDER BY o.created_at DESC LIMIT 20 OFFSET 100。OFFSET越大越慢，因为数据库仍要生成全部前100+20行再丢弃。
- 改用时间范围过滤：
WHERE o.created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)，再加ORDER BY，结果集从百万级压到几千 - 如果必须按全局顺序分页，用游标分页：
WHERE o.created_at ，避免OFFSET - 注意
created_at字段是否允许NULL，NULL值会干扰索引范围扫描，建议设NOT NULL并给默认值
EXPLAIN看懂真实执行路径，别信“走了索引”就安心
EXPLAIN里显示type: ref或range不代表排序被优化。关键要看Extra列：
- 出现
Using index condition：好，索引下推生效 - 出现
Using where; Using index：更好，覆盖索引搞定WHERE+SELECT - 只要带
Using filesort或Using temporary，说明排序/分组仍在内存或磁盘做，不管有没有索引
容易被忽略的一点：JOIN顺序影响索引选择。MySQL按FROM表顺序决定驱动表，如果users小、orders大，应写FROM users JOIN orders，否则优化器可能选错驱动表，导致大表全扫。
复杂点在于：当ORDER BY涉及多表字段（如u.name, o.created_at），几乎不可能用单个索引覆盖，这时要么拆查询，要么接受排序开销——没有银弹，只有权衡。
