子查询中ORDER BY无效，正确做法是将排序和LIMIT放在最内层子查询，并在外层再次ORDER BY以确保顺序；MyBatis中排序字段须用${v}拼接，不可用#{v}；GROUP BY后ORDER BY无效，应改用窗口函数或子查询。
子查询里写ORDER BY为什么没用
MySQL、PostgreSQL、SQL Server 等主流数据库都明确规定：ORDER BY 在派生表（即 FROM (SELECT ...) 这种子查询）中**不保证生效**，除非配合 LIMIT、OFFSET 或 TOP。这不是 bug，是 SQL 标准行为——子查询返回的是逻辑结果集，不是有序序列。
常见错误现象：SELECT * FROM (SELECT id, name FROM users ORDER BY created_at DESC) t，执行后顺序依然随机；尤其在 JOIN 或分页场景下，上层查询可能直接“重排”整个结果。
- SQL Server 会直接报错：“
ORDER BY子句在视图、内联函数、派生表、子查询和公用表表达式中无效”，除非加TOP 100 PERCENT（但依然不可靠） - MySQL 5.7+ 会静默忽略子查询里的
ORDER BY，不报错也不执行 - PostgreSQL 允许语法通过，但优化器大概率丢弃该排序指令
想按某字段倒序取最新10条，正确写法是什么
核心原则：排序必须落在**最外层查询**，且不能被上层逻辑覆盖。如果目标是“先取最新10条再关联其他表”，就得把排序和限制一起放在最内层，并确保外层不破坏顺序语义。
例如：要查 zs_safe_confess 中启用的最新10条记录，并关联内容表和资源表：
SELECT D.*, C.*, R.* FROM ( SELECT * FROM zs_safe_confess WHERE ENABLE = 1 ORDER BY CREATE_TIME DESC, UPDATE_TIME DESC LIMIT 10 ) D LEFT JOIN zs_safe_confess_content C ON D.ID = C.CSAFE_ID LEFT JOIN zs_resources R ON D.ID = R.ID AND R.TYPE = 10 AND R.ENABLE = 1 ORDER BY D.CREATE_TIME DESC, D.UPDATE_TIME DESC;
-
LIMIT 10必须和内层ORDER BY绑定，否则 MySQL 不保证哪10条被选中 - 外层
ORDER BY是保险措施，防止 JOIN 后因执行计划变化导致顺序漂移（尤其在 MySQL 8.0 以前） - 别名
D不可省略，否则语法报错（如 SQL Server 要求子查询必须有别名）
MyBatis 动态排序参数传不进去，${v} 和 #{v} 到底怎么选
在 MyBatis 中，ORDER BY 后面不能用预编译占位符 #{v}，因为数据库不允许对排序字段做参数化绑定——它会被当成字符串字面量，比如 ORDER BY 'create_time'，而非列名。
必须用字符串拼接方式 ${v}，让字段名原样透传到 SQL 中：
SELECT * FROM users
WHERE status = 1
ORDER BY ${sortField} ${sortOrder}-
${sortField}值应为create_time、id等合法列名，不能带空格或 SQL 注入字符（需服务端白名单校验） -
${sortOrder}应为ASC或DESC，注意大小写敏感，部分数据库要求大写 - 绝对不要用
#{sortField}，否则生成的 SQL 是ORDER BY ?，数据库直接报语法错误
LEFT JOIN + GROUP BY + ORDER BY 一起用时排序总错乱
这是 MySQL 特有的执行顺序陷阱：GROUP BY 在 ORDER BY 之前执行。一旦用了 GROUP BY，每组只保留一条记录（MySQL 默认取第一行，非聚合字段值不确定），此时再 ORDER BY 已无意义。
典型场景：想按 predestine 分组，取每组 id 最大的那条。错误写法：
SELECT * 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;
正确解法是改用窗口函数（MySQL 8.0+）或相关子查询：
SELECT p.*, pp.*
FROM sl_predestine p
INNER JOIN sl_predestine_price pp ON p.id = pp.predestine
WHERE pp.member = 1
AND pp.id = (
SELECT MAX(pp2.id)
FROM sl_predestine_price pp2
WHERE pp2.predestine = pp.predestine
);- 避免在含
GROUP BY的查询中依赖ORDER BY控制“取哪一行” - MySQL 5.7 及更早版本不支持窗口函数，只能用子查询或临时表兜底
- 如果业务强依赖固定顺序，且无法升级 MySQL，建议在应用层做二次排序或缓存预计算结果
排序真正起作用的地方，永远只在最终输出那一层。嵌套越深，越容易误以为“里面排好了，外面就稳了”——其实只是还没触发重排而已。
