MySQL升级至8.0后ORDER BY结果“变乱”非bug，而是因排序算法变更导致非确定性：无索引时默认不保证相等值的稳定顺序；解决方法是为ORDER BY字段建索引，并添加唯一字段（如id）实现确定性排序。
MySQL升级后查询结果顺序“变乱”，不是bug，而是优化器行为变更的必然结果——尤其是5.7→8.0升级后，ORDER BY在无索引、多字段、分页等场景下，返回顺序可能和之前完全不同。靠“以前能跑”来判断现在是否正确，会踩坑。
ORDER BY 字段没索引时，8.0 排序逻辑已彻底改写
MySQL 8.0.20+ 废弃了 max_length_for_sort_data 参数，不再按“全字段排序 vs row_id 排序”二分策略，而是统一采用更激进的内存/磁盘混合排序（filesort），且默认不保证相同值的次序稳定性。
- 现象：同一语句在5.7中看似稳定（比如按
created_atDESC 返回总按插入顺序补位），8.0里却跨页重复或颠倒 - 根本原因：旧版可能隐式依赖主键顺序做“兜底”，新版完全交由排序算法决定，而算法本身对相等值不做稳定排序承诺
- 实操建议：
– 必须为ORDER BY字段建索引（哪怕只是单列）
– 若字段值常重复（如status、category），务必追加唯一性字段（如id）构成确定性排序：ORDER BY status DESC, id ASC
– 避免SELECT *+ORDER BY non_pk_col的组合，回表开销大，且8.0更易触发临时表
分页查询中 ORDER BY + LIMIT 出现跨页重复
这是升级后最典型的“顺序错乱”表现，本质是排序不满足**确定性（deterministic）**：当多个行在 ORDER BY 列上值相等时，MySQL 不保证它们之间的相对顺序一致。
- 错误写法：
SELECT * FROM logs ORDER BY created_at DESC LIMIT 20,10（created_at有大量相同秒级时间） - 后果：第1页最后一条和第2页第一条可能是同秒数据，但因内部排序抖动，第2页又把第1页某条“捞回来”
- 解决方式：
– 强制添加唯一二级排序字段：ORDER BY created_at DESC, id DESC（假设id自增）
– 对应建立联合索引：CREATE INDEX idx_created_id ON logs(created_at DESC, id DESC)
– 如果业务允许，用游标分页替代LIMIT offset（如记录上一页最大id，下一页查WHERE created_at ）
字符集与 collation 变更放大了排序“不可预测性”
MySQL 8.0 默认 collation_server = utf8mb4_0900_as_cs（区分大小写+重音），而老表常是 utf8mb4_unicode_ci。两者混用不仅报 Illegal mix of collations，还会让 ORDER BY 结果肉眼可见地“跳变”。
- 典型触发点：
JOIN中关联字段 collation 不一致、UNION各子查询字段 collation 不统一、函数如UPPER()返回值 collation 与字段不匹配 - 快速定位：
SHOW FULL COLUMNS FROM table_name查每列实际 collation；SELECT @@collation_server, @@collation_database看全局基准 - 稳妥修复路径：
– 优先统一字段 collation：ALTER TABLE t MODIFY c VARCHAR(100) COLLATE utf8mb4_0900_as_cs
– 临时兼容：在 SQL 中显式指定，如ORDER BY name COLLATE utf8mb4_unicode_ci（仅限过渡期）
– 避免改collation_server回退到旧规则，这会削弱新版本字符处理能力，且部分 collation 已被标记为 deprecated
真正麻烦的从来不是“怎么让它看起来有序”，而是“怎么让有序在任何并发、任何数据分布、任何 MySQL 小版本下都可重现”。升级后别信直觉，每个 ORDER BY 都要回答三个问题：排序字段有没有索引？值是否可能重复？重复时靠什么保证次序不漂移？漏掉任意一个，线上就可能出静默错乱。
