子查询中ORDER BY无效是SQL标准要求，因派生表被视为无序集合；仅当配合LIMIT、FETCH或TOP时才有效，用于截断而非保证顺序。
子查询里写 ORDER BY 没效果，不是数据库 bug，而是 SQL 标准强制要求：派生表（即 FROM (SELECT ...) 这种）必须被视为无序集合。
派生表为什么不能有顺序
SQL 把“表”定义为数学意义上的集合，而集合本身不带顺序。当你写 SELECT * FROM (SELECT id, name FROM users ORDER BY created_at DESC) t，数据库解析时会把括号里的部分当作一个中间结果集——它只负责提供数据内容，不承诺任何行序。优化器发现这个 ORDER BY 对上层没用（比如后面要 JOIN 或 GROUP BY），就直接丢掉，省得白算排序开销。
常见错误现象：
- MySQL 5.7 静默忽略，8.0+ 默认报错（除非加
LIMIT） - PostgreSQL 直接拒绝语法（
ERROR: ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET） - SQL Server 明确报错：
ORDER BY clause is not allowed in a VIEW, inline function, derived table, subquery, or common table expression
什么时候子查询的 ORDER BY 才算“有效”
只有两种情况它真起作用，而且目的都不是为了“让结果有序”，而是为了配合截断逻辑：
-
ORDER BY ... LIMIT N（MySQL/PostgreSQL）：此时排序是为取前 N 条服务的，LIMIT依赖顺序才能确定哪几行被选中 -
ORDER BY ... OFFSET 0 ROWS FETCH FIRST N ROWS ONLY（标准 SQL）：同理，FETCH必须基于明确顺序 -
TOP N ... ORDER BY（SQL Server）：TOP行为不可控，必须靠内层ORDER BY定义“最新”或“最前”
注意：这些都不是让你“信任子查询输出顺序”，而是让数据库知道“按什么规则截取”。一旦去掉 LIMIT/TOP，ORDER BY 就又失效了。
LEFT JOIN + GROUP BY + ORDER BY 一起用时最容易翻车
典型场景：想每组取最新一条记录，于是写成：
SELECT p.*, pp.* FROM sl_predestine p LEFT JOIN sl_predestine_price pp ON p.id = pp.predestine WHERE pp.member = 1 GROUP BY pp.predestine ORDER BY pp.id DESC;
结果每组拿到的却是 pp.id 最小的那条。原因很直接：GROUP BY 在 ORDER BY 之前执行，分组时 MySQL 从每组随机挑一行（通常是物理存储顺序的第一行），等排完序，只剩每组一条数据，再排也没意义。
正确做法是把排序和取值绑定在子查询里：
SELECT p.*, pp.* FROM sl_predestine p LEFT JOIN ( SELECT * FROM sl_predestine_price WHERE member = 1 ORDER BY id DESC LIMIT 10000 ) pp ON p.id = pp.predestine GROUP BY pp.predestine;
但更稳妥的是用窗口函数或关联子查询，避免依赖隐式行为。
MyBatis 动态传排序字段必须用 ${} 而非 #{}
ORDER BY 后面不能用预编译参数 #{sortField}，因为数据库不允许把列名当参数绑定——它会被当成字符串字面量处理，例如 ORDER BY 'create_time'，根本不会按字段排序。
必须用字符串拼接：ORDER BY ${sortField} ${sortOrder}，并确保传入值来自可信来源（如枚举或白名单校验），否则有 SQL 注入风险。
容易被忽略的一点：即使你在外层写了 ORDER BY，如果没建对应索引，或者排序字段存在大量重复值（比如 status 只有 0/1），数据库仍可能因执行计划变化、并发读取或缓冲区状态不同，导致两次查询返回顺序不一致——顺序可靠性永远绑定在“外层显式声明 + 索引支撑 + 唯一性保障”三者之上。
