使用Mybatis分页插件（PageHelper）导致数据量大时查询慢的解决方法

描述：
在项目中使用Mybatis分页插件分页查询十分缓慢，但是在数据库中执行速度却很快？
该数据库的表共有10000条数据，分页查询时，在数据库中是很快，但是在使用Mybatis分页插件的时候居然8s多！

原因：
PageHelper在做分页查询的时候,select count(0) 会先把原来的查询语句全部重新查询一遍（未做数量限制），然后再执行select count（0）操作，相当于查询两遍，导致查询速度慢。
例如：

select count(*) from ("原来的查询sql,相当于多查了一遍") user

sql打印：

SELECT count(0)
 FROM (SELECT V.*,B.TypeName AS TravelTypeName
 FROM (SELECT A.PKID, A.ApplyOrderNo FROM t1 AS A
 LEFT JOIN t2 AS P
 ON P.ApplyOrderNo = A.ApplyOrderNo
 LEFT JOIN t3 AS T
 ON A.UserCode = T.UserCode ) AS V
 LEFT JOIN t4 AS B
 ON V.TravelCode = B.TypeCode AND V.UserCode = B.UserCode AND B.Isdel = 0）

SELECT V.*,B.TypeName AS TravelTypeName
 FROM (SELECT A.PKID, A.ApplyOrderNo FROM t1 AS A
 LEFT JOIN t2 AS P
 ON P.ApplyOrderNo = A.ApplyOrderNo
 LEFT JOIN t3 AS T
 ON A.UserCode = T.UserCode ) AS V
 LEFT JOIN t4 AS B
 ON V.TravelCode = B.TypeCode AND V.UserCode = B.UserCode AND B.Isdel = 0

优化方案：
在原来的查询方法后面，加上"_COUNT",重写总数量查询方法，优化sql,覆盖默认的数量查询方法。

例如：原来的mapper层里面的查询方法：

Page<Map<String, Object>> getOrderInfo(Map<String, Integer> map);

重写一个方法，getOrderInfo后面加“_COUNT”：返回类型必须为Long

Long   getOrderInfo_COUNT();

然后在去xml中写具体sql：

<select id="getOrderInfo" resultType="Long" useCache="false">
	SELECT V.*,B.TypeName AS TravelTypeName
	 FROM (SELECT A.PKID, A.ApplyOrderNo FROM t1 AS A
	 LEFT JOIN t2 AS P
	 ON P.ApplyOrderNo = A.ApplyOrderNo
	 LEFT JOIN t3 AS T
	 ON A.UserCode = T.UserCode ) AS V
	 LEFT JOIN t4 AS B
	 ON V.TravelCode = B.TypeCode AND V.UserCode = B.UserCode AND   B.Isdel = 0
</select>
<select id="getOrderInfo_COUNT" resultType="Long" useCache="false">
	SELECT
	COUNT(1)
	FROM t1 
</select>

注：getDeviceOrderInfo_COUNT()方法里面的sql自定义完成，尽量减少不必要的表关联，提高查询速率。

总结：
分页插件中的计算Count的sql语句，会将需要分页的所有数据查出来然后生成一个临时表，再去计算Count。如果数据量比较大，生产临时表就多查询了一次表，会导致最后Count计算会十分慢，从而影响分页的结果。

解决办法：
​ 覆盖原Count的sql，根据官方文档自定义。注意返回值类型(Long)与方法名(原名_COUNT)