MyBatis-Flex分页查询数据重复问题分析与解决方案

问题背景

在使用MyBatis-Flex框架进行分页查询时，开发者可能会遇到一个特殊现象：当执行分页查询（如BaseMapper.paginate()方法）时，某些数据记录会异常地出现在多个分页结果中。例如：

• 设置pageSize=50时，某条数据同时出现在第二页第48位和第三页第23位
• 设置pageSize=100时，同一条数据又出现在第一页第98位和第二页第41位

这种异常现象会导致数据展示混乱，严重影响业务逻辑的正确性。

根本原因分析

经过深入排查，发现该问题与MySQL 5.6版本后对ORDER BY LIMIT语句的优化机制密切相关：

1. MySQL查询优化机制：自5.6版本起，MySQL对包含ORDER BY和LIMIT的查询语句进行了特殊优化。当排序过程中只需要保留LIMIT指定的N条记录时，MySQL会采用更高效的内存使用策略。

2. 堆排序的不稳定性：在这种优化场景下，MySQL内部使用了堆排序算法。堆排序属于不稳定的排序算法，当排序键的值相同时，记录的相对顺序可能在排序过程中发生变化。

3. 分页查询的本质：MyBatis-Flex的分页查询最终会转换为类似SELECT * FROM table ORDER BY xxx LIMIT offset, size的SQL语句。当offset值变化时，由于排序不稳定，可能导致同一条记录出现在不同分页中。

解决方案

针对这个问题，我们推荐以下解决方案：

方案一：添加唯一排序键

在原有ORDER BY子句后追加表的主键或唯一字段作为次要排序条件：

QueryWrapper query = QueryWrapper.create()
    .orderBy("create_time DESC")
    .orderBy("id ASC"); // 添加唯一主键排序
Page<Entity> page = mapper.paginate(Page.of(1, 50), query);

方案二：配置全局排序策略

如果项目中有大量分页查询，可以在MyBatis-Flex配置中设置默认的排序策略：

mybatis-flex:
  global-order-by: "id ASC" # 在所有排序后自动追加主键排序

技术原理深入

为什么添加唯一排序键能解决问题？

1. 排序稳定性保障：当ORDER BY包含唯一键时，MySQL必须严格按照所有排序字段进行排序，无法使用优化后的堆排序算法。

2. 执行计划变化：EXPLAIN分析显示，添加唯一排序后，MySQL会使用filesort的稳定排序算法而非优化后的优先队列排序。

3. 分页一致性：无论offset如何变化，每条记录都有确定的排序位置，不会因算法不稳定而"跳跃"到其他分页。

最佳实践建议

1. 分页必排序：所有分页查询都应该显式指定ORDER BY子句，避免依赖数据库默认排序。

2. 排序字段选择：

   • 首选业务上有意义的字段（如创建时间）
   • 必须包含唯一字段（如主键）作为最后排序条件

3. 性能权衡：

   • 大数据量表避免使用非索引字段排序
   • 复合索引应包含排序字段以提高性能

总结

MyBatis-Flex分页查询出现重复数据的问题，本质上是MySQL优化机制与分页需求的冲突表现。通过理解数据库底层的排序机制，我们可以采用追加唯一排序键的方案完美解决这个问题。这既保证了分页结果的准确性，又遵循了数据库的最佳实践。

在实际开发中，建议将这种解决方案形成编码规范，确保所有分页查询都能稳定可靠地工作。同时，对于关键业务的分页查询，还应该增加结果校验逻辑，确保数据一致性。