多字段排序本身稳定，但仅对完全相等的值保留原始顺序；真正影响可复现性的关键是null处理、排序方向显式声明及数据库引擎差异。
直接说结论：多字段排序本身是稳定的，但“稳定”只在值完全相等时才保留原始顺序；真正影响结果可复现性的，是 NULL 处理、排序方向显式声明、以及数据库引擎差异。
为什么 ORDER BY 多字段后结果有时“看起来乱”？
这不是排序不稳，而是你没意识到：SQL 标准不保证相等值之间的行序，除非你显式加入唯一键兜底。比如 ORDER BY status, created_at DESC 中，所有 status = 'done' 的记录，只要 created_at 也相同，数据库就可能任意排列它们——哪怕物理存储顺序没变，查询结果也不一定一致。
- MySQL 8.0+ 在无主键/唯一索引时，可能按扫描顺序返回，但不承诺稳定
- PostgreSQL 默认使用“tuplesort”算法，对完全相等的组不保序
- 如果业务要求“相同状态+相同时间的订单，按 id 升序排”，就必须写成：
ORDER BY status, created_at DESC, id ASC
NULL 值排序行为不统一，必须主动控制
NULL 在不同数据库里默认排最前还是最后，直接影响分页、前端展示逻辑。比如 ORDER BY discount DESC，MySQL 把 NULL 当最大值顶到开头，PostgreSQL 当最小值压到底部——同一句 SQL 在开发环境（MySQL）和生产环境（PostgreSQL）跑出来，首屏数据可能完全不同。
- 显式用
IS NULL或IS NOT NULL控制位置：例如ORDER BY discount DESC NULLS LAST（PostgreSQL 支持），但 MySQL 不支持该语法 - MySQL 替代方案：用
IFNULL(discount, -1)或COALESCE(discount, -1)把NULL转为确定值参与排序 - SQLite 需查编译选项，
NULLS FIRST/LAST不可用，只能靠表达式转换
ASC/DESC 只作用于紧邻字段，别依赖默认值
ORDER BY a, b DESC, c 的意思是：a ASC（默认）、b DESC（显式）、c ASC（又回到默认）。很多人以为 b DESC 会让后面所有字段都降序，实际不会——c 仍是升序。
- 每个字段都显式写
ASC或DESC，尤其 ORM 自动生成 SQL 时容易漏掉前面字段的ASC - 混合方向时注意语义分组：比如
ORDER BY category ASC, price DESC, name ASC表达的是“同类商品里贵的优先，同价再按名称字母排”，不是“整体价格从高到低” - Django ORM 的
.order_by('category', '-price', 'name')会生成对应 SQL，但调试时建议手动补全ASC验证
最容易被忽略的点：排序字段如果有函数或表达式（比如 ORDER BY UPPER(name)），不同数据库对函数结果的 NULL 和空字符串处理也不同；加上索引是否覆盖这些表达式，还会影响性能和结果一致性。别只盯着字段名，得盯住整个表达式的行为边界。
