join后order by变慢的根本原因是数据库无法复用单表索引完成连接后的排序，必须通过复合索引（如idx_user_created）使驱动表按on字段+排序字段有序读取，避免using filesort。
JOIN后ORDER BY变慢，不是排序本身的问题
根本原因是数据库无法复用单表索引完成连接后的排序。JOIN生成的是临时结果集，哪怕orders.created_at有索引，一旦和users表关联，优化器就大概率放弃走索引排序，转而触发Using filesort——尤其是数据量过万时，磁盘排序开销会指数级上升。
聚集索引对JOIN排序几乎没用
MySQL不支持用户自定义聚集索引（InnoDB主键即聚簇索引），PostgreSQL也没有传统意义的聚集索引；所谓“给连接字段建聚集索引”是常见误解。真正起作用的是**复合索引的顺序设计**，而非是否“聚集”。
-
CREATE INDEX idx_user_created ON orders (user_id, created_at DESC)才是关键：它让orders表能按user_id分组、再按created_at有序读取，JOIN时天然满足排序需求 - 如果只建
INDEX(created_at)，JOIN过程中仍需回表+二次排序，EXPLAIN里依然会出现Using temporary; Using filesort - 在SQL Server中，虽然支持
CLUSTERED INDEX，但若ON字段不是索引首列（如CLUSTERED INDEX(created_at, user_id)），JOIN仍无法利用其有序性
ORDER BY字段必须落在驱动表的复合索引里
优化器只有在驱动表扫描阶段就能按目标顺序读取数据，外层排序才能被消除。这意味着：
- 若用
LEFT JOIN users u ON o.user_id = u.id，orders是被驱动表，那idx_user_created必须存在且被选中；否则优化器可能先全扫orders再排序 - 若改用
INNER JOIN且users过滤性强（如WHERE u.status = 'active'），可尝试把users设为驱动表，并建INDEX(status, id)，让JOIN过程顺带按id有序输出 -
ORDER BY o.created_at DESC中字段来自被驱动表？那就必须确保该表的ON字段+排序字段组成最左前缀索引，缺一不可
容易被忽略的隐式陷阱
即使索引建对了，以下写法也会让优化器直接弃用：
- 在
ON或WHERE中对JOIN字段用函数：ON u.id = CAST(o.user_id AS SIGNED)→ 类型隐式转换，索引失效 - 排序字段参与计算：
ORDER BY o.created_at + INTERVAL 1 DAY→ 无法走索引，强制filesort -
NULL值大量存在且未显式处理：若created_at允许NULL，又没加WHERE o.created_at IS NOT NULL，优化器可能因选择性低而跳过索引 - MySQL 8.0+默认不启用
optimizer_switch='use_index_extensions=on'，导致复合索引的覆盖能力被低估
最终效果不取决于“有没有索引”，而在于执行计划里type是否为ref或range，以及Extra是否出现Using index而非Using filesort。
