Mysql + order by limit

我们经常会使用order by 和limit 在做数据查询时排序，限定条数或者是分页排序，平时运用中也没有发现什么异常。但最近的一个项目使用这种方法查询时发现了一个严重的问题，我在用Job导入数据时，因为存在同时导入了大量的数据，数据的创建时间DataChange_CreateTime只精确到时分秒，存在同样时间的数据。在用order by limit 分页查询，且筛选一定条数的时候，出现结果不一致的情况。查询数目(即limit 的数据) 为10 和 1000的时候，两者结果最初的10条数据不一致。查询资料发现问题所在，后文也会提供解决办法。记录下来，防止自己再次犯错的同时也给大家提个醒。

类似问题出现情景

现有一张表，表结构如下：

大概5000条数据， 大部分记录的flag都等于0，pay_time字段时间戳格式都正确

我们使用limit分批读取数据：

select id, pay_time from order_customer_new where flag=0 order by pay_time asc limit 250, 10;

读取数据的过程中，发现有时间戳相等的记录，分两次读取，可能会丢失某条记录。如下图所示，id=465的记录就丢失了。


这是什么情况，为啥id=465的数据会丢失呢？查询官方资料，有如下解释：

大概意思是说：如果你将Limit row_count与order by混用，mysql会找到排序的row_count行后立马返回，而不是排序整个查询结果再返回。如果是通过索引排序，会非常快；如果是文件排序，所有匹配查询的行（不带Limit的）都会被选中，被选中的大多数或者全部会被排序，直到limit要求的row_count被找到了。如果limit要求的row_count行一旦被找到，Mysql就不会排序结果集中剩余的行了。
总之，应该就是排序值相等造成了顺序的不确定导致的。

解决办法

如果想要在如上所述的情况下保证排序结果一致且正确，可以额外的增加一个排序条件，特别是增加唯一的主键字段为其中的一个排序条件，这样可以使得排序的结果唯一确定，往往都能解决问题。 例如上文查询中增加主键id为排序条件之一，查询结果就完全正确了。

注：本文的事例是直接利用 https://blog.csdn.net/tsxw24/article/details/44994835 这篇博文中的例子，实际项目中的例子因为考虑到隐私，没有引用。但结果即解决办法都是可行的。仅供大家参考。