MyBatis-Plus深度分页场景下的索引覆盖优化实践

背景概述

在数据库查询优化中，索引覆盖（Covering Index）是提升查询性能的重要手段。当查询语句只需要通过索引就能获取所需数据时，数据库引擎可以避免回表操作，显著提高查询效率。然而在MyBatis-Plus的分页查询场景中，默认的分页机制可能会与这种优化方式产生冲突。

问题分析

MyBatis-Plus的分页插件默认会在SQL的最外层添加LIMIT子句来实现分页。但在深度分页场景下，开发者通常会采用以下优化模式：

1. 先通过子查询利用覆盖索引快速定位符合条件的主键
2. 再通过主键IN查询获取完整数据

这种优化方式的分页逻辑应该作用于子查询层面，而非最外层。当MyBatis-Plus的LIMIT被添加到外层时，会导致：

• 子查询仍然返回大量数据
• 外层LIMIT无法有效减少实际查询量
• 失去了索引覆盖优化的意义

解决方案

方案一：自定义XML实现

对于需要精细控制分页逻辑的场景，建议绕过MyBatis-Plus的分页插件，直接在XML中编写完整SQL：

<select id="selectPageWithCoveringIndex" resultType="YourEntity">
    SELECT * FROM your_table 
    WHERE id IN (
        SELECT id FROM your_table 
        WHERE [查询条件]
        ORDER BY [排序字段]
        LIMIT #{offset}, #{size}
    )
</select>

这种方式可以：

• 精确控制分页作用于子查询
• 充分利用覆盖索引优化
• 避免不必要的数据扫描

方案二：分阶段查询

另一种可行的优化模式是分两步执行：

1. 先执行只返回ID的分页查询

Page<Long> idPage = new Page<>(pageNum, pageSize);
pageMapper.selectPageIds(idPage, queryWrapper);

2. 再通过获取的ID列表查询完整数据

List<YourEntity> entities = baseMapper.selectBatchIds(idPage.getRecords());

这种方案虽然需要两次数据库交互，但在深度分页场景下往往能获得更好的性能。

实践建议

1. 对于简单分页场景，仍可使用MyBatis-Plus默认分页
2. 当页码较大（如pageNum > 100）时，建议采用上述优化方案
3. 注意监控实际执行计划，确保优化方案确实利用了覆盖索引
4. 考虑添加适当的索引来支持覆盖查询

总结

MyBatis-Plus作为优秀的ORM框架，其默认分页机制能满足大多数场景需求。但在深度分页等特殊场景下，开发者需要根据实际情况灵活选择优化方案。通过合理利用索引覆盖等数据库特性，可以显著提升分页查询性能，特别是在大数据量场景下。

建议开发者在实施前充分测试不同方案的性能表现，选择最适合当前业务场景的优化方式。