分页必须用确定性order by（如主键或唯一时间戳），禁用非唯一字段排序；优先游标分页（where id>last_id）；严格校验page/size参数；缓存需绑定排序边界值。
分页时 WHERE 条件漏掉排序字段导致数据错乱
不加 ORDER BY 的分页查询，数据库返回顺序不保证，翻页时同一条记录可能出现在第 1 页和第 2 页，甚至消失。MySQL 8.0+ 默认优化器可能重排结果，尤其在有索引但未显式指定排序时。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有分页
SELECT必须带确定性ORDER BY，优先用主键（如ORDER BY id ASC）或唯一时间戳字段（如ORDER BY created_at DESC, id DESC） - 避免用
ORDER BY RAND()或非唯一字段（如ORDER BY status），否则LIMIT+OFFSET会跳行或重复 - 如果业务要求按热度排序，需先固化排序值（如加
hot_score列并定期更新），不能实时计算
用 OFFSET 分页在高并发下被删/插入数据导致偏移错位
LIMIT 20 OFFSET 40 这类写法本质是“跳过前 40 行再取 20 行”，但若第 35–45 行之间有记录被删除或新增，第 3 页就会漏掉或重复数据——这不是 Bug，是 SQL 语义决定的。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 改用游标分页（cursor-based pagination）：用上一页最后一条的
id作为下一页起点，例如WHERE id > 12345 ORDER BY id ASC LIMIT 20 - 游标必须基于排序字段且该字段有索引，否则性能暴跌；同时禁止用户手动修改 URL 中的游标值（需服务端校验有效性）
- 如必须用
OFFSET（如后台管理页），应加SELECT ... FOR UPDATE锁表（仅限事务内短操作），但会显著降低并发能力
分页参数未校验引发越权或 DB 崩溃
用户传入 ?page=-1&size=9999999 可能绕过权限、触发全表扫描，甚至拖垮 MySQL 内存（OFFSET 越大，MySQL 越要扫描前面所有行）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 强制校验
page和size：如$page = max(1, (int)$_GET['page'])，$size = min(100, max(1, (int)$_GET['size'])) - 对敏感接口（如订单列表），在分页前加权限检查，不能只靠前端隐藏链接
- 监控慢查询日志，重点抓
LIMIT后数字 > 1000 的请求，推动前端改用游标或限制最大页码
缓存分页结果时未绑定关键上下文导致脏数据
把 SELECT * FROM posts LIMIT 20 OFFSET 40 的结果缓存 10 分钟，但期间有新文章发布或旧文被删除，缓存就失效了——更麻烦的是，不同用户看到的“第 3 页”内容不一致。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 缓存 key 必须包含排序字段的边界值，例如
posts_list_asc_id_12345_12365（表示 id 从 12345 到 12365 的这批记录），而不是简单拼page=3 - 写操作（INSERT/UPDATE/DELETE）后，主动清除相关分页缓存，或用缓存失效策略（如基于时间戳版本号）
- 对实时性要求高的列表（如秒杀商品），直接禁用分页缓存，改用数据库直查 + 游标
真正难的不是写分页逻辑，而是让每一页都像快照一样稳定。游标分页、确定性排序、参数硬校验、缓存绑定边界值——这四点缺一不可。最容易被忽略的是：排序字段没索引，或者游标值没做存在性校验，结果看似分页正常，实际数据早就在悄悄漂移。
