分页查询在并发写入时会跳过或重复数据
MySQL 的
LIMIT offset, size分页本身不加锁，也不保证快照一致性——只要在查询执行过程中有新记录插入或旧记录删除，
ORDER BY id排序下的偏移位置就会漂移。典型现象是：用户翻页时某条记录“消失”，或下一页开头又出现上一页末尾的同一条记录。
根本原因是：InnoDB 默认的
REPEATABLE READ隔离级别只对**首次 SELECT 读取的数据行**建立一致性视图（consistent read view），但
OFFSET计算依赖的是实时索引扫描结果，不是快照里的行数。 插入新记录（尤其在排序字段前）→ 下一页
OFFSET对应的物理位置后移 → 跳过原应显示的记录 删除记录 → 同样偏移量指向新行 → 某条记录被重复查出 即使加了
SELECT ... FOR UPDATE，也只锁住当前查到的行，不锁住“将要被 OFFSET 跳过的那些间隙”
用游标分页（cursor-based pagination）替代 OFFSET
真正安全的方案是放弃数字偏移，改用上一页最后一条记录的排序字段值作为下一页起点，也就是游标分页。它天然规避了偏移漂移问题，且性能更好（可走索引范围扫描）。
要求：
ORDER BY字段必须有唯一性约束（如主键
id或联合唯一索引），否则无法精确定位下一页起始点。
SELECT * FROM orders WHERE id > 12345 ORDER BY id ASC LIMIT 20;上一页最后一条记录
id = 12345→ 下一页条件为
WHERE id > 12345插入新记录只会追加在末尾（
id更大），不影响已有游标逻辑 删除记录也不会导致“空洞跳跃”，因为游标基于值而非位置 注意：不能用
>=，否则可能重复返回
id = 12345这条
为什么不能靠事务隔离级别解决
把事务设成
SERIALIZABLE或显式加
SELECT ... LOCK IN SHARE MODE，看似“更安全”，但实际既低效又无效：
SERIALIZABLE会让所有读操作隐式加范围锁，极大降低并发度，还可能触发死锁
LOCK IN SHARE MODE只锁住本次查到的 20 行，不锁住
OFFSET跨过的那几千行，插入仍可发生 一致性读视图（consistent read view）在事务开始时就固定了可见版本，但
SELECT COUNT(*) + LIMIT类分页逻辑中，COUNT 是快照值，而 LIMIT 扫描是实时索引遍历——两者看到的数据状态不一致
count(*) 分页总数在并发下本身就是个伪需求
当业务需要显示“共 123456 条”，这个数字在用户点击“第 1 页”和“第 100 页”之间大概率已失效。高并发写入场景下，
SELECT COUNT(*) FROM table不仅慢，而且结果不具备业务意义。 用近似值替代：查
information_schema.TABLES中的
TABLE_ROWS（MyISAM 精确，InnoDB 是估算） 前端改用“加载更多”按钮，不显示总页数；或只显示“还有更多”，避免强一致性错觉 如果真需精确总数，必须加读锁或串行化处理，代价远超收益
游标分页不依赖总数，也不需要
COUNT，这才是面向并发的真实解法。最容易被忽略的一点是：游标值必须由服务端生成并透传，不能让前端拼接或猜测，否则游标被篡改会导致数据越界或泄露。
