问题有分页查询用户的接口，已通过测试，正在上线。测试环境突然报BUG，每个页面都有不同程度的数据重复。比如第一页出现了张三，第三页出现了张三。主要代码如下：PageMethod.startPage(query.getCurrPage(),query.getPageSize());列表<用户>users=userMapper.pages(query);返回新的PageInfo<>（用户）；第一反应是，可能是MyBatis-Plus有问题，或者是用错了。MyBatis-Plus官方文档推荐的方法与问题代码一致（不同版本）//第二种方法是Mapper接口的调用，推荐使用。PageHelper.startPage(1,10);Listlist=userMapper.selectIf(1);那么问题可能只会出现在SQL上。分析SQL表结构如下：CREATETABLE`gov_contract_customer_relation`(`id`bigintNOTNULLAUTO_INCREMENT,`no`varchar(50)NOTNULLCOMMENT'number',`name`varchar(50)NOTNULLCOMMENT'name',`age`intDEFAULTNULLCOMMENT'age',`create_time`timestampNULLDEFAULTCURRENT_TIMESTAMPCOMMENT'createdtime',PRIMARYKEY(`id`)USINGBTREE,UNIQUEKEY`no_UNI_IDX`(`no`)USINGBTREE)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4COLLATE=utf8mb4_general_ciCOMMENT='用户表';有问题的分页SQL如下：SELECT*FROMt_userWHEREage>20ORDERBYcreate_timeDESCLIMIT0,10;问题是在LIMIT0,10和LIMIT0,50的结果中，前10个数据不一致。有一个ORDERBY子句，测试时没有写操作，根据以往不同分页容量的经验，前10条数据应该是一致的。那么问题可能出在create_time的值上。查询所有的create_times，发现所有的值都是一样的。因为是测试环境，测试同学批量导入数据，所以create_time值是一样的。原因如果没有ORDERBY子句，MySQL不保证以任何特定顺序返回。我们可能会观察到类似默认排序的可重复结果，但MySQL对此不作任何保证，因此它不可靠。当ORDERBY子句使用所有相同的值进行排序时，会导致与没有ORDERBY子句相同的结果。解决方案SELECT*FROMt_userWHEREage>20ORDERBYcreate_timeDESC,noASClimit0,10;添加排序字段，避免所有相同的字段值无法排序。最好使用具有唯一约束的字段作为排序基础。
