啊，这个时候写的坏了的SQL，因为还有问题，没有注意，所以有重复的数据。 因为引用了PageHelper插件，所以期初觉得插件有问题。 事后想想，毕竟整个框架都在使用这个插件，即使有问题也应该早就出来了。 所以，首先考虑了SQL。 确实，去排序也没问题。
在上一个数据库中分页是后台常用的技术手段，如果说进行数据库查询可能会根据业务需要对字段进行排序，请访问当待排序字段值相同时，我们得到的查询结果会是什么呢
分页问题描述数据时，即使使用order by create_time desc，也必须根据数据记录创建时间create_time字段反转顺序，但前端请求时获取的数据正确
问题的原因我对期初还很感兴趣。 总数没有问题。 总咨询也没有问题。 为什么数据重复，以及复盖某些数据。 然后，查看SQL，它根据时间进行排序，而这正是许多数据在同一时间插入或设置在同一时间。
前后执行总搜索(即不分页)没有重复。
再次运行分页查询，并分两页运行查询，即可退出。 (而且，两次查询中出现的数据和总查询数据不同。)
然后，SQL发现对于ORDER BY 待排序字段值相同时，系统可能会将数据排序为随机。 也就是说，这个数据在前面和后面，所以翻页时容易看到重复的数据。
当然数据是重复的。 你不知道哪个是真的吗？ 哪个是假的？ 请参阅。 也就是说，第一页看到了123，第二页看到了345。 真正的排序可能是123645。
举个例子，可以从一系列数据中进行简单的实验。 以下是一系列实验数据，member_id字段为数据主键，数据的create_time字段完全相同
执行以下SQL，在create_time字段倒序查询上调查数据的结果如下。
select member_id，create _ timefrommemberorderbycreate _ time desc； 查询结果：
搜索结果显示数据排序变成了一种无序状态，这也是导致我们分页查询时出现重复数据的问题原因
运行以下SQL以在create_time字段中反向数据，然后运行再根据主键排序查询: 查询结果如下：
select member_id，create _ timefrommemberorderbycreate _ time desc，member_id； 我们发现数据恢复了有序状态。这也为我们提供了避免数据分页时待排序字段值相同情况时结果无序的解决方案。
在SQL中，ORDER BY为相同值且结果无序的具体原因，通过调查谷歌和相关资料，大致总结了造成这种情况的原因。 其实这种现象的发生是“故意”设计的。
有些人认为，如果未指定ORDER BY语句，且未指定SQL Server（或任何RDBMS）不保证以特定顺序返回结果order by子句，则行始终按集群索引或物理磁盘顺序返回。 但是，这是不正确的，因为在查询处理过程中有许多因素可以更改行的顺序。 例如，并行散列连接是更改行顺序的操作符的一个很好的示例。
如果指定ORDER BY语句，SQL Server将对行进行排序并按请求的顺序返回。 但是，如果该顺序不是确定性的，即可能有重复的值，则在每个具有相同值的组中，由于与上述相同的原因，该顺序是“随机的”
确保可靠顺序的唯一方法是在ORDER BY子句中包含有保证的唯一列或列组，如主键。
为了避免类似的问题，可以在需要排序的业务字段之后部署主键(或唯一字段)的排序。