Rui

测试转换没有发现问题，可以试试最新版本： ```java String sql = OrderByParser.converToOrderBySql("select * from user where length(name) > 0 order by id desc", "name desc"); Assert.assertEquals("SELECT * FROM user WHERE length(name) > 0 order by name...

这么大的数据量还这样分页吗？

如果能PR可以提交一下，如果不行，本周会先shade把代码包含进来，不在传递jsqlparser依赖。

当前PR暂时不要做后续处理了，会先考虑和4.7做兼容（已经接近完成）。

测试发现count为true,false不影响分页sql，没有问题。 `PageHelper.offsetPage(3, 4, true);` 参数对应的 hsql分页测试的SQL： ``` 23:07:16.377 [main] DEBUG c.g.p.mapper.UserMapper.selectAll - ==> Preparing: select * from user order by id -- comment LIMIT ? OFFSET ? 23:07:16.381 [main] DEBUG...

[CountSqlParser改为接口，允许通过countSqlParser参数替换为自己的实现，支持](https://github.com/pagehelper/Mybatis-PageHelper/commit/65e9fee782834ec89e310181d5de1bb41b67adf0) https://github.com/pagehelper/Mybatis-PageHelper/issues/772

首先这不算问题，主要是ThreadLocal线程绑定的原因，如果在mybatis中遇到类似拦截器，都需要手动在新线程上进行绑定。 你这种情况就别用异步count了。

有一个不检查的方法你试试

当前的设计不支持参数控制order by，后续考虑集成 mybatis-config 后再支持。

local使用过一次就会清理，不需要手动。。 还可以用 `try(Page ignored = PageHelper.startPage(1, 10)) {` 这种方式保证被清理