SQL查询结果顺序不可靠，必须显式使用ORDER BY；NULL排序行为因数据库而异，需用NULLS FIRST/LAST明确；复合排序应添加唯一字段兜底；窗口函数内ORDER BY不影响最终结果顺序。
ORDER BY 缺失时，SQL 查询结果顺序不可靠
不加 ORDER BY 的查询，数据库不保证返回行的顺序。即使某次执行看起来“有序”，那只是巧合——可能源于索引扫描顺序、数据物理存储位置或查询计划缓存，但这些都属于实现细节，不是 SQL 标准要求的行为。
常见错误现象：SELECT * FROM users WHERE status = 'active' 在开发环境总按 id 递增返回，上线后突然乱序，导致前端分页错乱或业务逻辑误判。
- MySQL 8.0+ 默认使用主键索引扫描时可能“碰巧”有序，但一旦加了
JOIN、GROUP BY或触发临时表，顺序立刻失效 - PostgreSQL 更激进：即使只查单表且有索引，也可能并行扫描打乱顺序
- SQL Server 在无
ORDER BY时明确声明“结果集顺序未定义”
ORDER BY 中 NULL 值的排序行为需显式控制
ORDER BY 子句里，NULL 的相对位置由数据库默认规则决定，且各系统不一致：MySQL 和 PostgreSQL 默认把 NULL 当作“最大值”（NULLS LAST），SQL Server 则当作“最小值”（NULLS FIRST）。不显式声明，跨库迁移或联合查询时容易出偏差。
示例：想让 updated_at 为空的记录排在最后：
ORDER BY updated_at ASC NULLS LAST
但注意：NULLS FIRST/LAST 在 MySQL 8.0.12+ 和 PostgreSQL 支持，旧版 MySQL 只能用 IS NULL 表达式模拟：
ORDER BY (updated_at IS NULL), updated_at ASC
复合 ORDER BY 的优先级和稳定性必须明确
多个字段排序时，顺序严格按书写先后生效：先比第一个字段，相等再比第二个，依此类推。但若排序字段存在大量重复值（比如按 status 排序，90% 行都是 'active'），最终结果仍不稳定——因为相等部分的内部顺序无定义。
解决方法是添加唯一性字段兜底，通常是主键：
- 安全写法：
ORDER BY status, id（假设id是主键） - 避免写法：
ORDER BY status, created_at（若created_at精度低或存在批量插入，仍可能重复） - PostgreSQL 还支持
ORDER BY status, ctid作为物理位置兜底，但不可移植，仅调试用
窗口函数里的 ORDER BY 不影响最终结果集顺序
在 OVER() 子句中写的 ORDER BY（如 ROW_NUMBER() OVER (ORDER BY score DESC)）只定义窗口内计算顺序，和整个查询返回行的排列无关。最终结果依然需要最外层的 ORDER BY 控制。
典型陷阱：
SELECT name, ROW_NUMBER() OVER (ORDER BY score DESC) AS rank FROM students;
这段语句不能保证输出按 score 降序排列——rank 列数值正确，但行本身可能随机排列。必须补上顶层排序：
SELECT name, ROW_NUMBER() OVER (ORDER BY score DESC) AS rank FROM students ORDER BY score DESC;
更隐蔽的问题是：某些 ORM 自动生成的分页查询会漏掉外层 ORDER BY，只依赖窗口函数里的排序，结果分页跳转时数据重复或丢失。
