ORDER BY 只对最终结果集生效，JOIN 不保证顺序；子查询/CTE 中的 ORDER BY 外层未复写则失效；ROW_NUMBER() 需确定性排序键；MySQL 5.7/8.0 均不保证 JOIN 默认有序；PG 中 LIMIT+ORDER BY 需索引优化。
ORDER BY 在 JOIN 后没生效，是因为没写在最后
SQL 中 ORDER BY 只对**最终结果集**起作用，而 JOIN 本身不改变顺序，也不保证顺序。如果你把 ORDER BY 写在子查询、视图或 CTE 里，但外层查询没再写，那排序就丢了——数据库只按执行计划返回的物理顺序给结果，不记住子查询里的 ORDER BY。
常见错误场景：
- 在
SELECT * FROM (SELECT ... FROM t1 JOIN t2 ON ... ORDER BY t1.id) AS tmp中，外层没ORDER BY，结果顺序不可靠 - 用
UNION拼接多个 JOIN 查询，每个分支写了ORDER BY，但没在外层统一控制 - ORM 自动生成 SQL 时，把排序逻辑塞进子句，主查询漏掉了
ORDER BY
LEFT JOIN 后 ROW_NUMBER() 排序错乱的典型原因
想用 ROW_NUMBER() OVER (ORDER BY ...) 给关联结果编号，却发现编号顺序和预期不符——大概率是窗口函数的 ORDER BY 子句没覆盖所有用于去重/分组的字段，或者 JOIN 引入了重复值导致排序键不唯一。
实操建议：
-
ROW_NUMBER()的ORDER BY必须包含足够多的确定性字段（比如加t1.id, t2.id而不只是t1.name） - 如果 LEFT JOIN 导致某行
t2字段为NULL，而你又按t2.created_at排序，这些NULL行会挤在一起且顺序未定义（不同数据库处理方式不同） - 先用
SELECT DISTINCT或GROUP BY去重再开窗，比直接在 JOIN 结果上开窗更可控
MySQL 5.7 vs 8.0 对 JOIN + ORDER BY 的行为差异
MySQL 5.7 默认可能“巧合地”保持 JOIN 输入表的顺序（尤其单表驱动时），但这属于未定义行为；MySQL 8.0 优化器更激进，常重排执行顺序，导致原来“看着正常”的 SQL 突然乱序。
关键点：
- MySQL 不保证任何 JOIN 类型（
INNER/LEFT/STRAIGHT_JOIN）的结果默认有序 -
STRAIGHT_JOIN只强制连接顺序，不保结果顺序；它甚至可能让ORDER BY更难命中索引 - 如果依赖排序，必须显式写
ORDER BY，且字段要落在能走索引的组合上（比如ON条件 +ORDER BY字段联合有索引）
PostgreSQL 中 JOIN 后 LIMIT + ORDER BY 的性能陷阱
写 SELECT ... FROM a JOIN b ON ... ORDER BY a.ts DESC LIMIT 10 很常见，但如果 a.ts 上没索引，或 JOIN 条件无法过滤掉大量数据，PG 可能先做笛卡尔积再排序再截断——慢得明显。
优化方向：
- 确保
ORDER BY字段所在表有对应索引，且该表是 JOIN 的驱动表（可用EXPLAIN看实际驱动顺序） - 若
b表很大但只需匹配少量a行，考虑先用LATERAL子查询：先取 top 10a行，再对每行查b，避免全量 JOIN - 不要指望
ORDER BY能“自动下推”到 JOIN 子句里——它永远作用于最终结果集，不是中间过程
排序不是 JOIN 的副作用，而是你必须主动声明的契约。只要没在最外层 SELECT 显式写 ORDER BY，就别假设顺序存在；哪怕现在看着对，换数据量、换版本、换优化器路径，都可能崩。
