mysql 8.0取消无索引order by的隐式稳定性非bug而是设计变更：因filesort重写且不保证相等值顺序，必须用联合索引（如created_at desc, id desc）加确定性排序子句实现deterministic结果。
MySQL 5.7 及更早版本中依赖“隐式排序”（比如靠主键顺序兜底、无索引 ORDER BY 看似稳定）的查询，在 8.0 升级后结果变乱，不是 bug，是设计变更——8.0 彻底放弃对相等值排序的稳定性承诺，必须显式构造确定性排序逻辑。
为什么无索引 ORDER BY 在 8.0 里不再“看起来稳定”
旧版 MySQL（尤其 5.7）在没索引时可能偶然沿用主键或插入顺序作为内部排序的“副作用”，让人误以为 ORDER BY created_at DESC 总能返回一致顺序；8.0 的 filesort 实现已重写，默认不保证相同值的相对次序，且彻底移除了 max_length_for_sort_data 的旧路径控制。哪怕只差一毫秒，两条记录的 created_at 相等，它们在结果集里的先后就不可预测。
- 现象：分页时第 1 页末尾和第 2 页开头出现重复行，或跨请求顺序颠倒
- 本质：排序不满足 deterministic（确定性），而 MySQL 8.0 明确不为此兜底
- EXPLAIN 中
type是ALL或filesort，且key为NULL，说明根本没走索引
ORDER BY 字段没索引时必须补联合索引
光加单列索引不够——如果 created_at 大量重复（如日志表秒级时间戳），仅 INDEX(created_at) 无法让排序稳定；必须把唯一字段（如自增 id 或时间精度更高的 created_at_micro）一起纳入索引和 ORDER BY 子句。
- 建索引：
CREATE INDEX idx_created_id ON logs(created_at DESC, id DESC); - 改查询：
ORDER BY created_at DESC, id DESC（顺序必须与索引一致） - 避免
SELECT *+ 无覆盖索引：回表开销大，8.0 更倾向走临时表，进一步放大抖动 - 注意：若用
ASC/DESC混合，确保 MySQL 版本 ≥ 8.0.12，否则降级为全表扫描
FIND_IN_SET、JOIN、UNION 报 Illegal mix of collations 怎么快速修
这不是排序问题本身，但常和它并发出现：当 ORDER BY 涉及多源字段（比如 JOIN 后排序），而两边字段 COLLATION 不一致（如一边是 utf8mb4_general_ci，另一边是默认的 utf8mb4_0900_ai_ci），MySQL 8.0 直接报错，连排序步骤都进不去。
- 查真实 collation：
SHOW FULL COLUMNS FROM your_table;，别信SHOW CREATE TABLE里的注释 - 临时绕过：
ORDER BY t1.name COLLATE utf8mb4_0900_ai_ci, t2.id DESC - 治本动作：
ALTER TABLE t1 MODIFY name VARCHAR(255) COLLATE utf8mb4_0900_ai_ci; - FIND_IN_SET() 必须两边显式对齐：
FIND_IN_SET(col COLLATE utf8mb4_0900_ai_ci, @var COLLATE utf8mb4_0900_ai_ci)
游标分页比 LIMIT offset 更可靠
当业务允许，用游标替代传统分页是最干净的解法——它天然规避了排序不确定性带来的跨页重复问题，也避开大 offset 的性能陷阱。
- 第一页：
SELECT * FROM logs ORDER BY created_at DESC, id DESC LIMIT 20; - 下一页（记下上一页最后一条的
(created_at, id)值）：SELECT * FROM logs WHERE (created_at, id) - 注意：WHERE 条件中的元组比较要求 MySQL ≥ 8.0.1，且字段顺序、方向必须与
ORDER BY完全一致 - 不能用字符串拼接模拟元组，否则索引失效
最容易被跳过的其实是排序字段的业务语义：比如 status 字段只有 'pending'/'done' 两类值，再怎么加 id 排序，物理顺序仍高度依赖 id 分布。这种场景下，索引有效性和查询稳定性其实取决于数据写入模式，不是加个 COLLATE 或改条 SQL 就能掩盖的。
