ORDER BY 缺失或不稳定导致分页重复的主因是排序字段不唯一，如 created_at 相同引发物理顺序不确定；应使用 ORDER BY created_at DESC, id DESC 确保唯一性，并优先采用游标分页替代 offset 分页。
为什么 ORDER BY 缺失或不稳定会导致分页重复
分页重复最常见原因不是 SQL 写错，而是排序依据不唯一。比如用 created_at 排序，但多条记录时间戳完全相同（尤其高并发插入），MySQL 可能每次返回不同物理顺序，LIMIT 20,10 就可能跳过或重复某几条。
- 必须确保
ORDER BY的字段组合在全表中具有唯一性，推荐加主键兜底：ORDER BY created_at DESC, id DESC - 避免用
ORDER BY RAND()或无索引字段排序，这会让执行计划不可预测 - 如果业务允许，优先用游标分页（cursor-based）替代偏移分页（offset-based），彻底避开
LIMIT跳跃问题
使用 mysqli 或 PDO 时，OFFSET 计算错误怎么查
PHP 层手动算 $offset = ($page - 1) * $per_page 看似简单，但容易在边界出错：第 1 页传了 0 还是 1？总页数变化后缓存没清？用户直接改 URL 参数？
- 永远对
$page做强校验：max(1, (int)$page)，防止负数或超大值导致OFFSET溢出 - 不要依赖前端传来的总页数或最后一页标识，每次分页查询都应基于当前条件重新 count，或用
SQL_CALC_FOUND_ROWS（注意：MySQL 8.0+ 已弃用） - 调试时在 SQL 前加
SELECT SQL_NO_CACHE，排除查询缓存干扰
WHERE 条件变更后分页数据漂移怎么办
用户在分页过程中修改筛选条件（比如切换状态、搜索关键词），但前端仍沿用旧的 page 参数，后端没重置分页上下文，结果新条件下的第 2 页，恰好包含旧条件第 1 页末尾的数据。
- 所有影响结果集的参数（包括搜索词、状态、时间范围）都必须参与分页键哈希或缓存 key 构建，不能只认
page和limit - 接口设计上，把分页和筛选绑定为原子操作；避免「先查总数 → 再查列表」两步分离，中间状态可能已变
- 如果用 Redis 缓存分页结果，key 中必须包含完整查询参数的 MD5，例如：
"page:users:{$hash}"，而不是固定写死"page:users"
游标分页（cursor-based）在 PHP 中怎么落地
用游标代替数字页码，核心是「记住上一页最后一条的排序字段值」，下一页查询就从这个值之后开始。它不依赖总条数，也不怕数据实时增删，天然解决重复和跳跃。
立即学习“PHP免费学习笔记（深入）”；
- 查询语句示例：
SELECT * FROM posts WHERE status = 1 AND (created_at, id) - PHP 中需把上一页最后一条的
created_at和id拼成 base64 或 JSON 传给前端，别暴露原始值（防篡改/越权） - 注意 NULL 处理：如果排序字段允许 NULL，必须显式定义
NULLS LAST（PostgreSQL）或在 MySQL 中用IFNULL(created_at, '1970-01-01')统一补值
游标分页没法跳转到任意页，这是代价。但如果你的场景是「加载更多」或信息流，这才是真正可靠的分页方式。别为了支持「跳到第 100 页」牺牲数据一致性。
