在近期的项目开发中，我们遇到过一个比较隐蔽的问题：列表页和导出功能的排序逻辑看似相同，但实际返回的数据顺序却对不上。
当时场景是这样的：列表字段较多，且有一个全量导出功能。由于导出内容涉及的字段与列表展示不完全一致，加上要求无分页导出，我没有复用列表的通用数据源方法。测试时发现，导出的数据顺序和列表里显示的不一样。更奇怪的是，调整列表的分页大小似乎也会影响排序效果。
起初我怀疑是 MySQL 执行顺序的问题，毕竟官方文档说先排序后分页，理论上分页大小不该影响排序结果。排查了一圈资料后发现，问题的根源在于 ORDER BY 的字段存在重复值。当排序关键字段的值相同时，MySQL 并不保证返回结果的稳定性，每次查询可能会随机取到不同的行，这就导致了顺序不一致。
那为什么同样的 SQL 在客户端工具里跑没问题呢？这通常是因为客户端或服务器端的缓存机制。如果查询结果命中了缓冲池（Buffer Pool）或者慢查询日志里的缓存，顺序可能固定；而 Java 程序每次发起实时查询时，受线程调度、内存分配等因素影响，底层存储引擎读取数据的物理顺序可能不同，导致最终结果集波动。
解决方案其实很简单
既然不稳定的原因是排序键不够唯一，那就给它加一个'锚点'。在 ORDER BY 后面追加一个具有唯一性的字段，比如主键 ID。
-- 原始写法（不稳定）
SELECT * FROM table_name ORDER BY sort_column DESC;
-- 修正后（稳定）
SELECT * FROM table_name ORDER BY sort_column DESC, id DESC;
加上 id 作为第二排序条件后，即使 sort_column 的值相同，系统也会根据 id 进行二次区分，从而确保无论何时查询，返回的顺序都是严格一致的。这在涉及数据导出、报表生成等对顺序敏感的场景下尤为重要。