使用MySQL的LIMIT和OFFSET时为何出现记录丢失问题？

这种分页过程中出现记录丢失的情况，在处理大数据量分页时确实很常见，我帮你梳理几个最可能的原因：

1. 排序字段不唯一（核心诱因） #

你的查询用了 order("position DESC")，如果多个产品的position值相同，数据库在对这些记录排序时，没有固定的次级排序键（比如主键id），那么相同position的记录返回顺序是不确定的——数据库每次执行查询时，可能会根据存储位置、索引状态等因素调整它们的排列顺序。

举个例子：假设产品14和20的position值相同，当你第一次取offset=0的10条记录时，14排在前面被包含进去；但当你取offset=10时，数据库调整了相同position记录的顺序，20被排在了14前面，而14则被挤到了offset=20的分页里，导致当前页看不到14，反而出现了20、21这类原本不在预期里的记录。

解决思路：给排序语句加上唯一的次级键，比如主键，改成 order("position DESC, id ASC")，这样就能保证相同position的记录始终按固定顺序排列，分页结果不会乱。

2. 分页过程中数据发生了变更 #

在你两次分页查询的间隙（比如从取offset=0到取offset=10的这段时间），如果Product表发生了以下操作，都会导致记录丢失或出现非预期结果：

• 插入新记录：新上线的产品（live=true）的position值较高，插入后会排在现有记录前面，导致原来的第10条及以后的记录整体后移，这时取offset=10就会跳过原本的第10条，取到后面的记录（比如例子里的21）。
• 更新现有记录：比如原本的产品14被修改了live状态为false，或者它的position值被调低，那么在offset=10的查询里，14就不会被包含进来；或者产品20的position被调高，进入了当前分页的范围。
• 删除记录：如果offset=0到offset=10之间的某条记录被删除，后面的记录会补上来，导致offset=10的查询会多取后面的一条记录，同时跳过原本的某条。

3. 数据库分页的底层实现限制 #

有些数据库（比如MySQL）在处理大offset的分页时，是先扫描并跳过offset条记录，再取limit条。这个过程中，如果表的数据有变化（比如索引更新、数据移动），会导致扫描的结果和预期不一致。不过这种情况更多出现在offset非常大的时候，但也是可能的诱因之一。

内容的提问来源于stack exchange，提问作者Rakshitha