Mybatis的通用分页插件，简化分页查询代码。 GitHub源码地址： https://github.com/pagehelper/Mybatis-PageHelper 支持 MyBatis 3.1.0+ 该插件目前支持以下数据库的物理分页:

这里的数据库列表更新不及时，详情看这里: PageAutoDialect.java#L58

引入分页插件有下面2种方式，推荐使用 Maven 方式。

你可以从下面的地址中下载最新版本的 jar 包

https://oss.sonatype.org/content/repositories/releases/com/github/pagehelper/pagehelper/

http://repo1.maven.org/maven2/com/github/pagehelper/pagehelper/

由于使用了sql 解析工具，你还需要下载 jsqlparser.jar(需要和PageHelper 依赖的版本一致) ：

在 pom.xml 中添加如下依赖：

最新版本号可以从首页查看。

特别注意，新版拦截器是 com.github.pagehelper.PageInterceptor。 com.github.pagehelper.PageHelper 现在是一个特殊的 dialect 实现类，是分页插件的默认实现类，提供了和以前相同的用法。

使用 spring 的属性配置方式，可以使用 plugins 属性像下面这样配置：

分页插件提供了多个可选参数，这些参数使用时，按照上面两种配置方式中的示例配置即可。

分页插件可选参数如下：

下面几个参数都是针对默认 dialect 情况下的参数。使用自定义 dialect 实现时，下面的参数没有任何作用。

helperDialect：分页插件会自动检测当前的数据库链接，自动选择合适的分页方式。 你可以配置helperDialect属性来指定分页插件使用哪种方言。配置时，可以使用下面的缩写值： oracle,mysql,mariadb,sqlite,hsqldb,postgresql,db2,sqlserver,informix,h2,sqlserver2012,derby 特别注意：使用 SqlServer2012 数据库时，需要手动指定为 sqlserver2012，否则会使用 SqlServer2005 的方式进行分页。 你也可以实现 AbstractHelperDialect，然后配置该属性为实现类的全限定名称即可使用自定义的实现方法。

offsetAsPageNum：默认值为 false，该参数对使用 RowBounds 作为分页参数时有效。 当该参数设置为 true 时，会将 RowBounds 中的 offset 参数当成 pageNum 使用，可以用页码和页面大小两个参数进行分页。

rowBoundsWithCount：默认值为false，该参数对使用 RowBounds 作为分页参数时有效。 当该参数设置为true时，使用 RowBounds 分页会进行 count 查询。

pageSizeZero：默认值为 false，当该参数设置为 true 时，如果 pageSize=0 或者 RowBounds.limit = 0 就会查询出全部的结果（相当于没有执行分页查询，但是返回结果仍然是 Page 类型）。

reasonable：分页合理化参数，默认值为false。当该参数设置为 true 时，pageNumpages（超过总数时），会查询最后一页。默认false 时，直接根据参数进行查询。

params：为了支持startPage(Object params)方法，增加了该参数来配置参数映射，用于从对象中根据属性名取值， 可以配置 pageNum,pageSize,count,pageSizeZero,reasonable，不配置映射的用默认值， 默认值为pageNum=pageNum;pageSize=pageSize;count=countSql;reasonable=reasonable;pageSizeZero=pageSizeZero。

supportMethodsArguments：支持通过 Mapper 接口参数来传递分页参数，默认值false，分页插件会从查询方法的参数值中，自动根据上面 params 配置的字段中取值，查找到合适的值时就会自动分页。 使用方法可以参考测试代码中的 com.github.pagehelper.test.basic 包下的 ArgumentsMapTest 和 ArgumentsObjTest。

autoRuntimeDialect：默认值为 false。设置为 true 时，允许在运行时根据多数据源自动识别对应方言的分页 （不支持自动选择sqlserver2012，只能使用sqlserver），用法和注意事项参考下面的场景五。

closeConn：默认值为 true。当使用运行时动态数据源或没有设置 helperDialect 属性自动获取数据库类型时，会自动获取一个数据库连接， 通过该属性来设置是否关闭获取的这个连接，默认true关闭，设置为 false 后，不会关闭获取的连接，这个参数的设置要根据自己选择的数据源来决定。

aggregateFunctions(5.1.5+)：默认为所有常见数据库的聚合函数，允许手动添加聚合函数（影响行数），所有以聚合函数开头的函数，在进行 count 转换时，会套一层。其他函数和列会被替换为 count(0)，其中count列可以自己配置。

重要提示：

当 offsetAsPageNum=false 的时候，由于 PageNum 问题，RowBounds查询的时候 reasonable 会强制为 false。使用 PageHelper.startPage 方法不受影响。

单独看每个参数的说明可能是一件让人不爽的事情，这里列举一些可能会用到某些参数的情况。

如果你仍然在用类似ibatis式的命名空间调用方式，你也许会用到rowBoundsWithCount， 分页插件对RowBounds支持和 MyBatis 默认的方式是一致，默认情况下不会进行 count 查询，如果你想在分页查询时进行 count 查询， 以及使用更强大的 PageInfo 类，你需要设置该参数为 true。

注： PageRowBounds 想要查询总数也需要配置该属性为 true。

如果你仍然在用类似ibatis式的命名空间调用方式，你觉得 RowBounds 中的两个参数 offset,limit 不如 pageNum,pageSize 容易理解， 你可以使用 offsetAsPageNum 参数，将该参数设置为 true 后，offset会当成 pageNum 使用，limit 和 pageSize 含义相同。

如果觉得某个地方使用分页后，你仍然想通过控制参数查询全部的结果，你可以配置 pageSizeZero 为 true， 配置后，当 pageSize=0 或者 RowBounds.limit = 0 就会查询出全部的结果。

如果你分页插件使用于类似分页查看列表式的数据，如新闻列表，软件列表， 你希望用户输入的页数不在合法范围（第一页到最后一页之外）时能够正确的响应到正确的结果页面， 那么你可以配置 reasonable 为 true，这时如果 pageNum总页数 会查询最后一页。

如果你在 Spring 中配置了动态数据源，并且连接不同类型的数据库，这时你可以配置 autoRuntimeDialect 为 true，这样在使用不同数据源时，会使用匹配的分页进行查询。 这种情况下，你还需要特别注意 closeConn 参数，由于获取数据源类型会获取一个数据库连接，所以需要通过这个参数来控制获取连接后，是否关闭该连接。 默认为 true，有些数据库连接关闭后就没法进行后续的数据库操作。而有些数据库连接不关闭就会很快由于连接数用完而导致数据库无响应。所以在使用该功能时，特别需要注意你使用的数据源是否需要关闭数据库连接。

当不使用动态数据源而只是自动获取 helperDialect 时，数据库连接只会获取一次，所以不需要担心占用的这一个连接是否会导致数据库出错，但是最好也根据数据源的特性选择是否关闭连接。

如果和Spring集成不熟悉，可以参考下面两个

只有基础的配置信息，没有任何现成的功能，作为新手入门搭建框架的基础

这两个集成框架集成了 PageHelper 和 通用 Mapper。

示例：* https://github.com/abel533/MyBatis-Spring-Boot

引入项目依赖

Spring DevTools 配置

感谢emf1002提供的解决方案。

在使用 DevTools 时，通用Mapper经常会出现 class x.x.A cannot be cast to x.x.A。

同一个类如果使用了不同的类加载器，就会产生这样的错误，所以解决方案就是让通用Mapper和实体类使用相同的类加载器即可。

DevTools 默认会对 IDE 中引入的所有项目使用 restart 类加载器，对于引入的 jar 包使用 base 类加载器，因此只要保证通用Mapper的jar包使用 restart 类加载器即可。

在 src/main/resources 中创建 META-INF 目录，在此目录下添加 spring-devtools.properties 配置，内容如下：

使用这个配置后，就会使用 restart 类加载加载 include 进去的 jar 包。

完整配置可以参考 src/main/resources/application-old.yml ，和 MyBatis 相关的部分配置如下：

注意 mapper 配置，因为参数名固定，所以接收参数使用的对象，按照 Spring Boot 配置规则，大写字母都变了带横线的小写字母。针对如 IDENTITY（对应i-d-e-n-t-i-t-y）提供了全小写的 identity 配置，如果 IDE 能自动提示，看自动提示即可。

示例： https://github.com/abel533/Mybatis-Spring

只有紧跟在PageHelper.startPage方法后的第一个Mybatis的查询（Select）方法会被分页。

请不要在系统中配置多个分页插件(使用Spring时,mybatis-config.xml和Spring配置方式，请选择其中一种，不要同时配置多个分页插件)！

对于带有for update的sql，会抛出运行时异常，对于这样的sql建议手动分页，毕竟这样的sql需要重视。

由于嵌套结果方式会导致结果集被折叠，因此分页查询的结果在折叠后总数会减少，所以无法保证分页结果数量正确。

分页插件支持以下几种调用方式：

下面对最常用的方式进行详细介绍

使用这种调用方式时，你可以使用RowBounds参数进行分页，这种方式侵入性最小，我们可以看到，通过RowBounds方式调用只是使用了这个参数，并没有增加其他任何内容。

分页插件检测到使用了RowBounds参数时，就会对该查询进行物理分页。

关于这种方式的调用，有两个特殊的参数是针对 RowBounds 的，你可以参看上面的 场景一 和 场景二

注：不只有命名空间方式可以用RowBounds，使用接口的时候也可以增加RowBounds参数，例如：

注意： 由于默认情况下的 RowBounds 无法获取查询总数，分页插件提供了一个继承自 RowBounds 的 PageRowBounds，这个对象中增加了 total 属性，执行分页查询后，可以从该属性得到查询总数。

除了 PageHelper.startPage 方法外，还提供了类似用法的 PageHelper.offsetPage 方法。

在你需要进行分页的 MyBatis 查询方法前调用 PageHelper.startPage 静态方法即可，紧跟在这个方法后的第一个MyBatis 查询方法会被进行分页。

想要使用参数方式，需要配置 supportMethodsArguments 参数为 true，同时要配置 params 参数。 例如下面的配置：

在 MyBatis 方法中：

当调用这个方法时，由于同时发现了 pageNumKey 和 pageSizeKey 参数，这个方法就会被分页。params 提供的几个参数都可以这样使用。

除了上面这种方式外，如果 User 对象中包含这两个参数值，也可以有下面的方法：

当从 User 中同时发现了 pageNumKey 和 pageSizeKey 参数，这个方法就会被分页。

注意：pageNum 和 pageSize 两个属性同时存在才会触发分页操作，在这个前提下，其他的分页参数才会生效。

ISelect 接口方式除了可以保证安全外，还特别实现了将查询转换为单纯的 count 查询方式，这个方法可以将任意的查询方法，变成一个 select count(*) 的查询方法。

PageHelper 方法使用了静态的 ThreadLocal 参数，分页参数和线程是绑定的。

只要你可以保证在 PageHelper 方法调用后紧跟 MyBatis 查询方法，这就是安全的。因为 PageHelper 在 finally 代码段中自动清除了 ThreadLocal 存储的对象。

如果代码在进入 Executor 前发生异常，就会导致线程不可用，这属于人为的 Bug（例如接口方法和 XML 中的不匹配，导致找不到 MappedStatement 时）， 这种情况由于线程不可用，也不会导致 ThreadLocal 参数被错误的使用。

但是如果你写出下面这样的代码，就是不安全的用法：

这种情况下由于 param1 存在 null 的情况，就会导致 PageHelper 生产了一个分页参数，但是没有被消费，这个参数就会一直保留在这个线程上。当这个线程再次被使用时，就可能导致不该分页的方法去消费这个分页参数，这就产生了莫名其妙的分页。

上面这个代码，应该写成下面这个样子：

这种写法就能保证安全。

如果你对此不放心，你可以手动清理 ThreadLocal 存储的分页参数，可以像下面这样使用：

这么写很不好看，而且没有必要。

这篇文档涉及下面几个方面

在 MyBatis 的拦截器的文档部分，我们知道 Executor 中的 query 方法可以被拦截，如果你真正写过这个方法的拦截器， 你可能会知道在 Executor 中的 query 方法有两个：

这两个方法的区别是第一个方法多两个参数 CacheKey 和 BoundSql，在多数情况下，我们用拦截器的目的就是针对 SQL 做处理，如果能够拦截第一个方法，可以直接得到 BoundSql 对象，就会很容易的得到执行的 SQL，也可以对 SQL 做处理。

虽然想的很好，但是 MyBatis 提供的 Exctutor 实现中，参数多的这个 query 方法都是被少的这个 query 方法在内部进行调用的。

在 CachingExecutor 中：

在 BaseExecutor 中：

上面这两个方法一样。由于第一个 query 方法在这里是内部调用，并且我们所有的拦截器都是层层代理的 CachingExecutor 或基于 BaseExecutor 的实现类，所以我们能拦截的就是参数少的这个方法。

分页插件开始从 Executor 拦截开始就一直是拦截的参数少的这个方法。但是从 5.0 版本开始，query 的这两个方法都可以被拦截了。在讲这个原理之前，我们先了解一下拦截器的执行顺序。

拦截器的调用顺序分为两大种，第一种是拦截的不同对象，例如拦截 Executor 和 拦截 StatementHandler 就属于不同的拦截对象， 这两类的拦截器在整体执行的逻辑上是不同的，在 Executor 中的 query 方法执行过程中，会调用下面的代码：

在这段代码中，才会轮到 StatementHandler 去执行，StatementHandler 属于 Executor 执行过程中的一个子过程。 所以这两种不同类别的插件在配置时，一定是先执行 Executor 的拦截器，然后才会轮到 StatementHandler。所以这种情况下配置拦截器的顺序就不重要了，在 MyBatis 逻辑上就已经控制了先后顺序。

第二种拦截器的顺序就是指拦截同一种对象的同一个方法，例如都拦截 Executor 的 query 方法，这时你配置拦截器的顺序就会对这里有影响了。假设有如下几个拦截器，都是拦截的 Executor 的 query 方法。

在org.apache.ibatis.session.Configuration 中有如下方法：

MyBatis 会按照拦截器配置的顺序依次添加到 interceptorChain 中，其内部就是 List interceptors。再看 Configuration 中创建 Executor 的代码：

在调用 interceptorChain.pluginAll 之前，executor 就是前一节中的 CachingExecutor 或基于 BaseExecutor 的实现类。 然后看 interceptorChain.pluginAll 方法：

前面我们配置拦截器的顺序是1，2，3。在这里也会按照 1，2，3 的顺序被层层代理，代理后的结构如下：

从这个结构应该就很容易能看出来，将来执行的时候肯定是按照 3>2>1>Executor>1>2>3 的顺序去执行的。 可能有些人不知道为什么3>2>1>Executor之后会有1>2>3，这是因为使用代理时，调用完代理方法后，还能继续进行其他处理。处理结束后，将代理方法的返回值继续往外返回即可。例如：

对于 Interceptor2.query 方法也是相同的逻辑：

同理 Interceptor1.query ：

叠加到一起后，如下：

所以这个顺序就是 3>2>1>Executor>1>2>3。

在你弄清楚这个逻辑后，再继续往下看，因为后面的技巧会颠覆这个逻辑，所以才会有后面的规范以及如何配置不同的插件。

上一节的内容中，对拦截器的用法是最常见的一种用法，所以才会出现这种都能理解的执行顺序。但是分页插件 5.0 不是这样，这个插件颠覆了这种顺序，这种颠覆其实也很普通，这也是本节要说的技巧。

在我写作 MyBatis 技术书籍的过程中（还没写完，已经因为分页插件占用了几周的写作时间），我就在考虑为什么不能拦截第一个 query（6个参数的）方法， 如果能拦截这个方法，就可以直接拿到 BoundSql，然后处理 SQL 就很容易实现其他的操作。

在第 1 节介绍为什么第一个 query 方法不能被拦截时，是因为下面这段代码：

既然 CachingExecutor 或基于 BaseExecutor 的实现类只是这么简单的调用两个方法得到了 BoundSql 和 Cachekey，我们为什么不直接替代他们呢？

所以我们可以有类似下面的拦截器用法：

这个拦截器直接替代了原有 Executor 的部分逻辑，直接去调用了 6 个参数的方法，因而导致 4 个参数的后续方法被跳过了。但是由于这里的 executor 是代理对象 所以 6 个参数的 query 方法可以被代理了，这就扰乱了上一节中的执行顺序。

在上一节拦截器的例子中，做简单修改，将 ExecutorQueryInterceptor2 换成上面的 QueryInterceptor，配置如下：

代理后的结构如下：

这时，调用顺序就变了，Interceptor3 执行顺序如下：

QueryInterceptor.query 执行逻辑如下：

在 QueryInterceptor 中，没有继续执行 4个参数方法，而是执行了 6 个参数方法。 但是 Interceptor1 拦截的 4 个参数的方法，所以 Interceptor1 就被跳过去了，整体的执行逻辑就变成下面这样了：

如果 Interceptor1 拦截的是 6 个参数的方法，因为 QueryInterceptor 获取的是 Interceptor1 代理的 executor 对象，那么 Interceptor1 就会被 QueryInterceptor 继续执行下去。

分页插件就是类似 QueryInterceptor 的执行逻辑，所以当你使用 5.0 版本之后的插件时，如果你还需要配置其他 Executor 的 query 插件，你就会遇到一些问题（可以解决，继续往下看）。

如果你是自己开发的插件，那么你按照下一节的规范去开发也不会遇到问题。如果你使用的其他人提供的插件，按照第 5 节的配置顺序也能解决问题。

QueryInterceptor 的逻辑就是进去的是 4 个参数的方法，出去的是 6 个参数的方法。这种处理方法不仅仅不方便和一般的 Excutor 拦截器搭配使用， 当出现两个以上类似 QueryInterceptor 的插件时，由于接口变了，类似 QueryInterceptor 插件也无法连贯的执行下去。 因而有必要解决这个问题。解决的办法就是使用统一的规范。经过规范后 QueryInterceptor 如下：

注意两个变化，第一个就是拦截器签名同时拦截了 4 个 和 6 个参数的方法，这样不管那个插件在前在后都会被执行。

第二个变化就是这段代码：

如果这个插件配置的靠后，是通过 4 个参数方法进来的，我们就获取这两个对象。如果这个插件配置的靠前，已经被别的拦截器处理成 6 个参数的方法了， 那么我们直接从 args 中取出这两个参数直接使用即可。取出这两个参数就保证了当其他拦截器对这两个参数做过处理时，这两个参数在这里会继续生效。

假设有个排序插件和分页插件，排序插件将 BoundSql 修改为带排序的 SQL 后，SQL 会继续交给分页插件使用。分页插件的分页 SQL 执行时，会保留排序去执行， 这样的规范就保证了两个插件都能正常的执行下去。

所以如果大家想要使用这种方式去实现拦截器，建议大家遵守这个规范。

这个规范对于已经存在的插件来说就没法控制了，但是仍然可以通过配置顺序来解决。

当引入类似 QueryInterceptor 插件时，由于扰乱了原有的插件执行方式，当配置 Executor 顺序不对时会导致插件无法生效。

第 4 节中的例子：

首先执行顺序为 3>Query>1>Executor，由于 Query 是 4 或 6 个参数进来，6 个参数出去。 所以在 Query 前面执行的拦截器必须是 4 个的（Query 规范拦截器先后都能执行，需要根据逻辑配置先后）参数的，在 Query 后面执行的拦截器必须是 6 个参数的。

这个顺序对应到配置顺序时，也就是 4 个参数的配置在 QueryInterceptor 拦截器的下面，6 个参数的配置在 QueryInterceptor 拦截器的上面。 按照这个顺序进行配置时，就能保证拦截器都执行。

如果你想获得如分页插件（QueryInterceptor 规范）执行的 SQL，你就得按照 QueryInterceptor 规范去实现，否则只能配置在分页插件的下面，也就只能获得分页处理前的 SQL。