MySQL官方明确允许ORDER BY字段重复时结果不确定，根本原因是其设计不保证相同排序值行的相对顺序；唯一可靠解法是追加唯一非空字段（如id）构成确定性复合排序。
ORDER BY字段值重复时结果不稳定
MySQL官方明确说明：当ORDER BY列存在多行相同值时，服务器“可以自由地以任何顺序返回这些行”，且该顺序可能随执行计划变化而变化——比如加了LIMIT、用了不同索引、甚至只是缓冲区大小微调，都可能导致两次查询结果顺序不一致。
常见现象包括：分页跨页重复（第一页的id=10086出现在第二页）、同一SQL反复执行返回不同行序、本地测试稳定但上线后乱序。
- 根本原因不是bug，而是设计：MySQL只保证
ORDER BY字段的相对顺序，不承诺其他列的排列方式 - 不要指望“没改数据就一定不变”——哪怕表里只有10条记录，只要
created_at相同，ORDER BY created_at的结果就不可靠 - 加主键
id是最常用兜底手段，但必须显式写进ORDER BY，不能依赖“它反正会按主键排”
必须用确定性复合排序
单一时间字段或状态字段几乎必然存在重复值，所以ORDER BY created_at DESC这种写法在生产环境等同于埋雷。真正安全的做法是补一个唯一或高区分度字段，构成确定性排序链。
- 推荐组合：
ORDER BY status ASC, created_at DESC, id ASC——每个方向都显式声明，避免误以为DESC会“传染”到前面字段 - 如果
id是自增主键，它天然提供全局唯一性和插入时序，是最佳次要排序字段 - 慎用
ORDER BY 2这类位置排序：一旦SELECT字段调整（比如加了个COUNT(*)），整个排序逻辑就崩了，多数DBA规范明令禁止 - 字符串字段参与排序时注意
COLLATE：比如name COLLATE utf8mb4_unicode_ci和utf8mb4_0900_as_cs对大小写/重音处理不同，会导致前后端排序不一致
索引要覆盖完整排序字段
即使写了正确的ORDER BY，没配好索引照样出问题：MySQL可能放弃走索引而改用filesort，不仅慢，还可能因内存/临时表机制引入额外不确定性。
- 建索引优先按排序字段顺序来：
CREATE INDEX idx_status_created_id ON orders(status, created_at DESC, id ASC) - 避免在
ORDER BY里用表达式：ORDER BY UPPER(name)或price * quantity会让索引失效；应提前计算好存为生成列或冗余字段 - MySQL 8.0+ 支持降序索引，但5.7不支持，建索引时若写
DESC会被忽略，实际仍是升序存储——此时ORDER BY x DESC仍可能触发filesort - 用
EXPLAIN确认是否走了索引：重点看type是否为index或range，Extra里有没有Using filesort
导出和分页场景要特别防坑
界面列表看着正常，导出CSV却顺序错乱？分页第一页和第二页数据重复？大概率是ORDER BY没写全，或导出逻辑复用了带LIMIT的SQL。
- 导出脚本必须剥离
LIMIT和OFFSET，否则只导出第一页数据；别信“前端传个export=true就自动删LIMIT”的动态拼接逻辑，容易漏判 - 分页查询中，
LIMIT本身会影响执行计划，导致和无LIMIT的排序结果不一致——这是MySQL文档白纸黑字写的，不是玄学 - 前端禁止二次排序：后端已按
name排好，前端再用Array.sort()重排，一旦JS的localeCompare()和MySQL的collation规则不一致（比如中文拼音 vs Unicode码点），顺序立刻失控 - NULL值行为数据库间差异大：MySQL升序时
NULL在最前，PostgreSQL在最后；需要稳定表现就得显式控制，如ORDER BY IFNULL(discount, -1) DESC
最常被忽略的一点：所谓“修复了排序”，往往只是暂时压住了现象。只要ORDER BY里缺了能打破并列的字段，或者索引没覆盖全部排序列，换台服务器、升个版本、加个并发线程，乱序就会重现。
