join后order by触发using filesort是因为连接生成的临时结果集无法复用单表索引，数据库必须对整个中间结果做外部排序；索引仅对原表有效，不覆盖join后的逻辑结构。
为什么JOIN后ORDER BY会触发Using filesort
因为连接生成的临时结果集无法复用单表索引，数据库被迫对整个中间结果做外部排序。比如orders有created_at索引、users有id主键，但JOIN ... ORDER BY orders.created_at仍会走Using filesort——索引只对原表有效，不覆盖JOIN后的逻辑结构。
常见错误现象：EXPLAIN里同时出现Using temporary和Using filesort，哪怕加了LIMIT 20也慢，说明排序发生在分页之前。
- 真正瓶颈不是
ORDER BY本身，而是它作用在未索引的连接结果上 - 如果
WHERE条件没走索引，排序前还要全表扫描JOIN，雪上加霜 - MySQL 8.0+虽支持
LATERAL或物化CTE，但默认不启用，得手动改写
用复合索引把排序“提前”到JOIN过程中
核心是让排序字段和JOIN字段落在同一个复合索引里，使优化器能按序读取数据，跳过事后排序。
例如查“每个用户最新订单”，别写SELECT ... FROM users u JOIN orders o ON ... ORDER BY o.created_at DESC这种被动排序；先建索引：CREATE INDEX idx_user_created_id ON orders (user_id, created_at DESC, id)，再配合子查询或窗口函数：
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
-
(user_id, created_at)顺序不能颠倒：(created_at, user_id)对JOIN无加速效果 -
DESC只影响扫描方向，匹配ORDER BY ... DESC可避免反向遍历 - 高频写入场景下，
created_at DESC可能加剧B+树页分裂，需权衡
用WHERE提前过滤，比ORDER BY更早剪枝
排序慢的根因常是中间结果集太大。与其让数据库对10万行排序，不如让它只JOIN 100行。
典型反例：FROM orders JOIN users ON ... WHERE users.status = 'active' ORDER BY orders.created_at DESC LIMIT 20 OFFSET 100——先连再排再切片，全量JOIN不可避免。
- 把时间范围等强过滤条件尽量往前压，比如
WHERE orders.created_at > '2026-06-01'放在JOIN前 - 对驱动表加覆盖索引，如
INDEX(status, id)，让WHERE users.status = 'active'直接定位小结果集 - 若业务允许，用
STRAIGHT_JOIN强制小表（如带状态过滤的users）当驱动表
避免在JOIN后对计算字段或NULL值排序
窗口函数如ROW_NUMBER()在JOIN后排序，若ORDER BY字段含NULL或来自表达式，极易触发磁盘排序。
LEFT JOIN引入的NULL会让ORDER BY score DESC把NULL排最前，导致排名错乱；ON a.id = b.ref_id + 1这类表达式则让索引失效，间接破坏排序路径。
- 显式控制NULL位置：MySQL用
COALESCE(score, -999999)，PostgreSQL用NULLS LAST - 避免在
ON条件里用函数或计算，如DATE(o.created_at) = u.reg_date，改用范围查询 - 确认是否真需
RANK()：仅取前N条用ROW_NUMBER()更可控；并列且需跳号才用RANK()
真正卡住性能的，往往不是JOIN本身，而是排序时机和索引覆盖的错配——一个EXPLAIN就能暴露问题，但修复需要把排序逻辑从“事后补救”变成“事前安排”。
