mybatis拦截器实现分页的核心在于利用其动态修改sql的能力，通过以下步骤构建通用分页插件：1. 定义page类封装分页参数；2. 实现interceptor接口并拦截statementhandler的prepare方法；3. 通过反射获取mappedstatement和boundsql对象；4. 判断是否需要分页处理；5. 构建count查询获取总记录数；6. 根据数据库类型生成分页sql；7. 替换原始sql并放行执行。该方式相比其他方案更优雅，具备解耦性强、通用性高、性能优、控制粒度细等优势，尤其避免了rowbounds内存分页的效率问题，并支持多数据库方言适配。核心技术点包括sql解析与重写、数据库方言抽象设计、反射操作内部字段及参数处理，挑战在于复杂sql兼容性、count查询性能优化、事务隔离影响和mybatis版本升级带来的维护成本。在spring boot中集成时，需将插件声明为bean并通过配置注册，业务层使用时只需传入page对象即可完成自动分页逻辑。
MyBatis插件实现分页的核心在于利用其拦截器（Interceptor）机制，在SQL执行前动态地修改sql语句，加入分页逻辑（如LIMIT/OFFSET），并同时执行一个COUNT查询来获取总记录数。这种方式能够将分页逻辑从业务代码中彻底解耦，实现通用且灵活的分页解决方案，同时兼顾不同数据库的方言差异。
解决方案
要构建一个完整的MyBatis分页插件，我们通常会遵循以下步骤和核心逻辑：
-
定义分页参数对象： 创建一个Page类，包含pageNum（当前页码）、pageSize（每页大小）、total（总记录数）和list（当前页数据列表）等属性。这个对象将作为方法参数或通过特定方式传递给插件。
-
实现MyBatis Interceptor 接口： 这是插件的核心。我们需要拦截StatementHandler的prepare方法。
- 注解拦截点： 使用@Intercepts和@Signature注解指定拦截的目标对象（StatementHandler）和方法（prepare）。prepare方法是MyBatis准备SQL语句的关键环节。
- 获取原始信息： 在intercept方法中，通过反射获取StatementHandler内部的MappedStatement（包含SQL语句ID、结果映射等）和BoundSql（包含原始SQL、参数等）。
- 判断是否需要分页： 根据MappedStatement的ID约定（例如，以ByPage结尾）或检查方法参数中是否存在我们定义的分页Page对象，来决定是否对当前SQL进行分页处理。
- 构建并执行总记录数查询：
- 从原始SQL中提取出用于计数的部分（通常是去除ORDER BY、LIMIT等，包裹在select COUNT(*) FROM (…) AS total中）。
- 创建一个新的MappedStatement和BoundSql来执行这个COUNT SQL。
- 利用MyBatis的Executor执行这个COUNT查询，获取总记录数。
- 将总记录数设置到传入的Page对象中。
- 构建分页SQL： 根据当前数据库类型（mysql、oracle、postgresql等），将原始SQL改写为带有分页子句（如LIMIT offset, limit）的SQL。这通常需要一个“数据库方言”抽象。
- 替换原始SQL： 使用反射将BoundSql中的原始SQL替换为分页后的SQL。
- 放行： 调用invocation.proceed()让MyBatis继续执行修改后的SQL。
- plugin方法： 实现plugin方法，判断目标对象是否是StatementHandler，如果是则使用Plugin.wrap包装目标对象。
- setProperties方法： 用于接收配置属性，例如数据库方言类型。
-
配置插件： 在MyBatis的配置文件（如mybatis-config.xml或spring boot的application.yml）中注册这个拦截器。
核心代码结构示意 (简化版，仅展示关键逻辑点):
@Intercepts({@Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class})}) public class PaginationInterceptor implements Interceptor { private String databaseType; // 例如：mysql, oracle @Override public Object intercept(Invocation invocation) throws Throwable { StatementHandler statementHandler = (StatementHandler) invocation.getTarget(); MappedStatement mappedStatement = (MappedStatement) ReflectUtil.getFieldValue(statementHandler, "mappedStatement"); BoundSql boundSql = statementHandler.getBoundSql(); Object parameterObject = boundSql.getParameterObject(); // 检查参数中是否包含Page对象，或者根据MappedStatement ID判断 Page<?> page = findPageObject(parameterObject); if (page == null) { return invocation.proceed(); // 不进行分页 } String originalSql = boundSql.getSql(); Connection connection = (Connection) invocation.getArgs()[0]; // 1. 执行总记录数查询 String countSql = DialectFactory.getDialect(databaseType).getCountSql(originalSql); long total = executeCount(mappedStatement, connection, parameterObject, countSql); page.setTotal(total); // 2. 构建分页SQL String pageSql = DialectFactory.getDialect(databaseType).getPaginationSql(originalSql, page.getOffset(), page.getPageSize()); ReflectUtil.setFieldValue(boundSql, "sql", pageSql); // 使用反射替换SQL return invocation.proceed(); } // 省略 findPageObject, executeCount, DialectFactory 和 ReflectUtil 工具类实现 // DialectFactory 内部会根据 databaseType 返回对应的数据库方言实现，如 MySQLDialect, OracleDialect // MySQLDialect 会实现 getCountSql 和 getPaginationSql 方法 // ReflectUtil 是一个简单的反射工具类，用于获取/设置私有字段 }
为什么选择MyBatis拦截器实现分页？它比其他方式好在哪里？
我个人觉得，MyBatis拦截器在实现分页方面确实是“优雅”这个词的代名词。它提供了一种非侵入式的、高度可配置的解决方案，这在实际项目中非常有用。
首先，解耦性极佳。业务代码完全不需要关心分页SQL的拼接，也不需要手动计算OFFSET和LIMIT。你的Mapper接口方法可以保持最原始、最纯粹的SQL定义，比如List
其次，通用性和可扩展性强。通过拦截器，我们可以轻松地实现数据库方言的适配。MySQL用LIMIT，Oracle用ROWNUM，SQL Server用TOP或OFFSET FETCH，这些差异都被封装在插件内部的方言实现里。当你的项目需要从MySQL迁移到Oracle时，你只需要修改一下插件的配置参数，而不需要改动任何业务SQL。这种灵活性是手动分页或者基于RowBounds的内存分页无法比拟的。
再者，相比MyBatis自带的RowBounds，拦截器方案解决了其内存分页的效率问题。RowBounds虽然也能实现分页，但它是在数据库查询出所有结果后，再在内存中进行截取。对于大数据量查询，这简直是灾难性的，会造成大量的内存消耗和不必要的网络传输。而拦截器则是在SQL执行前就将分页逻辑注入，让数据库只返回你需要的那一页数据，效率自然高得多。
最后，与一些成熟的第三方分页插件（如PageHelper）相比，自定义拦截器虽然需要自己编写更多代码，但它提供了极致的控制权。如果你对分页逻辑有特殊需求，或者不想引入额外的第三方依赖，自定义拦截器是最佳选择。它让你对分页的每一个细节都了如指掌，能够根据项目的具体情况进行深度优化。在我看来，这种“掌控感”在某些场景下是无价的。
实现MyBatis分页插件需要关注哪些核心技术点和潜在挑战？
实现MyBatis分页插件，说实话，一开始可能会觉得有点“黑科技”的味道，因为它确实深入到了MyBatis的内部机制。有几个核心技术点是必须掌握的，同时也会遇到一些挑战。
核心技术点：
- SQL解析与重写： 这是最核心也最复杂的部分。你需要能够从原始SQL中提取出用于计数的部分（例如，去除ORDER BY、LIMIT等子句），并将其包裹成SELECT COUNT(*) FROM (…)的形式。同时，还要能根据分页参数（页码、每页大小）将原始SQL改写成带有数据库特定分页子句的SQL。这通常涉及到正则表达式匹配或者更复杂的SQL AST（抽象语法树）解析。我个人在处理复杂SQL时，就曾被一些嵌套子查询、union操作搞得焦头烂额，这部分的代码健壮性非常重要。
- 数据库方言抽象： 不同的数据库有不同的分页语法。因此，你需要设计一个Dialect接口，包含getCountSql(String sql)和getPaginationSql(String sql, int offset, int limit)等方法，然后为MySQL、Oracle、PostgreSQL等主流数据库提供具体的实现类。这样可以保持插件的通用性。
- MyBatis内部反射机制： MyBatis的很多核心对象（如BoundSql的sql字段）都是私有的，为了修改它们，你必须使用Java的反射机制。例如，ReflectUtil.setFieldValue(boundSql, “sql”, newSql)。虽然反射很强大，但它也带来了一定的脆弱性——MyBatis版本升级时，如果内部字段名或结构发生变化，你的插件可能就会失效。这是一个需要权衡的风险点。
- 参数处理与总记录数回写： 如何将分页参数（如PageNum、PageSize）传递给插件？通常是通过方法参数中的一个特定对象（比如我们定义的Page对象）。更重要的是，插件在执行完COUNT查询后，需要将总记录数回写到这个Page对象中，以便业务层获取。这同样可能需要反射来操作参数对象。
潜在挑战：
- 复杂SQL的兼容性： 这是最头疼的问题。简单的SELECT * FROM table当然没问题，但遇到包含GROUP BY、HAVING、UNION、DISTINCT、LEFT JOIN以及各种复杂子查询的SQL时，自动生成正确的COUNT SQL和分页SQL就变得异常困难。例如，带有GROUP BY的SQL，直接COUNT(*)可能就不对了，需要COUNT(DISTINCT some_column)或更复杂的子查询。这需要你的SQL解析逻辑足够智能和健壮。
- 性能问题： 虽然拦截器避免了内存分页，但如果COUNT SQL生成不当，或者原始SQL本身效率低下，COUNT查询仍然可能成为性能瓶颈，甚至导致全表扫描。优化COUNT SQL的生成逻辑，尽量利用索引，是需要仔细考虑的。
- 事务隔离级别： 计数查询和实际数据查询是两次独立的SQL执行。在某些严格的事务隔离级别下（如可重复读），如果在这两次查询之间有数据发生变化，理论上可能导致总记录数与实际返回数据条数不一致的问题。虽然在多数Web应用场景下影响不大，但了解这一点很重要。
- 反射的维护成本： 前面提到了，MyBatis内部结构的变动可能导致反射代码失效。这意味着每次MyBatis大版本升级时，你可能都需要检查并更新你的插件代码。这就像是在一个不断变化的沙滩上盖房子，需要持续关注。
总的来说，实现分页插件是一个很好的深入理解MyBatis内部机制的机会，但也确实需要你做好应对各种“奇葩”SQL和反射带来的潜在问题的准备。
如何在Spring Boot项目中集成和配置MyBatis分页插件？
在Spring Boot项目中集成MyBatis分页插件，得益于Spring Boot的自动配置能力，其实比想象中要简单得多。一旦你的分页插件类（比如PaginationInterceptor）写好了，接下来的配置工作就非常顺畅了。
-
创建插件类： 确保你的PaginationInterceptor类已经编写完成，并且它实现了org.apache.ibatis.plugin.Interceptor接口。
-
定义分页参数对象： 确保你有一个Page类（或者你喜欢的任何名字），它包含了分页所需的信息，比如pageNum、pageSize，以及用来存放总记录数total和结果列表list的字段。
-
配置为Spring Bean： 最简单也是最推荐的方式，就是将你的PaginationInterceptor声明为一个Spring Bean。Spring Boot会自动检测到这个Bean，并将其注册到MyBatis的SqlSessionFactory中。
import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.util.Properties; @Configuration public class MyBatisConfig { @Bean public PaginationInterceptor paginationInterceptor() { PaginationInterceptor interceptor = new PaginationInterceptor(); // 如果你的插件需要配置属性，例如数据库方言 Properties properties = new Properties(); properties.setProperty("databaseType", "mysql"); // 示例：设置数据库类型 interceptor.setProperties(properties); return interceptor; } }你也可以在application.yml或application.properties中直接配置，但通过Java Config声明为Bean更灵活，尤其是在需要传递属性时。
通过application.yml配置（如果插件支持无参构造器且无需额外属性）：
mybatis: mapper-locations: classpath:mapper/*.xml configuration: # plugins 属性是一个列表，可以添加多个插件 plugins: - com.yourcompany.plugin.PaginationInterceptor # 替换为你的插件完整包名
我个人更倾向于Java Config，因为它能更好地处理插件初始化时的属性注入，比如你可能需要通过构造器注入一些依赖，或者设置一些运行时参数。
-
在业务代码中使用： 在你的Service层或Controller层，当你需要进行分页查询时，只需将你的Page对象作为参数传递给Mapper方法。插件会在后台默默地完成SQL的改写和总记录数的查询。
// 假设你的Mapper接口方法 public interface UserMapper { List<User> selectUsers(Page<User> page); // 传入Page对象 } // 在Service层调用 @Service public class UserService { @Autowired private UserMapper userMapper; public Page<User> findUsersByPage(int pageNum, int pageSize) { Page<User> page = new Page<>(pageNum, pageSize); // 初始化分页对象 List<User> users = userMapper.selectUsers(page); // 调用Mapper方法 page.setList(users); // 将查询结果设置回Page对象 return page; } }这里要注意的是，插件通常会在执行完COUNT查询后，将total值设置到你传入的Page对象中。而实际的列表数据list，则是在Mapper方法执行结束后由MyBatis返回的，你需要手动将它设置回Page对象。
集成过程中，我觉得最舒服的就是Spring Boot的“约定优于配置”理念。只要你的插件符合MyBatis拦截器的规范，并且被Spring识别为一个Bean，它就会自动帮你处理好剩下的事情。这省去了很多手动配置SqlSessionFactoryBean的繁琐步骤，让你可以更专注于插件本身的逻辑实现。当然，如果遇到问题，Spring Boot的日志通常会给出很清晰的提示，帮助你快速定位。
