必须使用唯一组合的ORDER BY（如created_at, id）配合游标分页，否则无序或重复值会导致LIMIT/OFFSET结果不可预测；隐式排序不可依赖，索引需覆盖全部排序字段。
ORDER BY 缺失时 LIMIT / OFFSET 的结果不可预测
MySQL 和 PostgreSQL 都不保证在没有 ORDER BY 的情况下，LIMIT 和 OFFSET 返回稳定的结果。即使表数据没变，两次执行 SELECT * FROM users LIMIT 10 OFFSET 20 也可能返回不同行——因为数据库可能按任意物理顺序（如插入顺序、索引遍历顺序、缓存页顺序）读取数据。
这不是 bug，是标准行为。SQL 标准明确要求：**无显式排序时，结果集顺序无定义**。
- PostgreSQL 可能按堆表的 tid 顺序扫描，但 vacuum 或并发写入后会变
- MySQL 在 InnoDB 中可能按主键聚簇索引顺序，但若查询走二级索引+回表，顺序又不同
- 哪怕加了
WHERE status = 'active'，只要没ORDER BY，仍不保序
ORDER BY 字段存在重复值时仍可能不一致
即使写了 ORDER BY created_at，如果多行 created_at 值相同（比如批量插入、毫秒级时间戳、或业务逻辑未严格控制），MySQL 和 PostgreSQL 对“相等值如何排序”没有统一约定。它们各自可能引入隐式次级排序（如 MySQL 按主键补位，PostgreSQL 按 ctid），但该行为不公开、不承诺、不可依赖。
典型现象：分页跳过或重复某几条记录，尤其在高并发写入场景下更明显。
- 修复方式：必须让
ORDER BY子句具备唯一性，例如ORDER BY created_at, id - 注意
id类型：若用 UUID 或非自增主键，需确认其分布是否足够离散 - 避免用
ORDER BY RAND()分页——它彻底破坏可预测性，且性能极差
MySQL 5.7 vs 8.0 与 PostgreSQL 12+ 的隐式排序差异
MySQL 5.7 在某些索引扫描路径下会“看起来有序”，但这只是实现巧合；MySQL 8.0 明确移除了多数隐式排序假设，更严格遵循 SQL 标准。PostgreSQL 自 9.0 起就坚持无 ORDER BY 则无序，但它的 ctid 行地址在 VACUUM 后会重排，导致同一查询跨时间点结果漂移。
这意味着：不能靠“以前跑得对”来判断当前逻辑安全。
- 迁移时尤其危险：把 PostgreSQL 的分页 SQL 直接扔进 MySQL（或反之），即使带
ORDER BY，若字段有重复值，行为仍可能不一致 - MySQL 的
sql_mode=ONLY_FULL_GROUP_BY不影响LIMIT/OFFSET排序，别混淆 - PostgreSQL 的
OFFSET性能随偏移量增大线性下降，而 MySQL 在大OFFSET下同样要跳过大量行——两者都建议改用游标分页（WHERE created_at > ? AND id > ?）
游标分页为什么能绕过排序一致性陷阱
基于最后一页末尾记录的排序字段值构造下一页条件（例如 WHERE created_at > '2024-01-01' OR (created_at = '2024-01-01' AND id > 12345)），本质是把“第 N 页”转换为“大于某锚点”，完全规避 OFFSET 的跳跃式扫描和排序依赖。
这要求：排序字段组合必须唯一、非空、有高效索引支持。
- 索引必须覆盖全部
ORDER BY字段，例如CREATE INDEX idx_created_id ON users(created_at, id) - 不能用函数包装排序字段，如
ORDER BY DATE(created_at)—— 索引失效，退化为全表扫描 - 若业务允许，优先用单调递增字段（如自增
id或nanoid）做主游标，比时间戳更可靠
分页不是简单加个 LIMIT 就完事；真正难的是让“下一页”这个概念在分布式、并发、异构数据库环境下依然有确定含义。越早放弃 OFFSET，越少掉进排序幻觉的坑。
