mybatisplus执行自定义sql时,多出一个limit
1.在使用MyBatis执行SQL(包含分页功能)的时候,明明SQL里没写LIMIT,执行时却多出了一个LiMIT。2.在使用MyBatis执行SQL的时候,明明SQL里写的是SELECT * …,执行时却执行了SELECT count(0) …,后文中对此Bug进行说明。解决方案:分页查询数据之前先清理分页缓存。原因:PageHelper 方法使用了静态的 ThreadLocal 参数,分页参数
1.在使用MyBatis执行SQL(包含分页功能)的时候,明明SQL里没写LIMIT,执行时却多出了一个LiMIT。
2.在使用MyBatis执行SQL的时候,明明SQL里写的是SELECT * …,执行时却执行了SELECT count(0) …,后文中对此Bug进行说明。
解决方案:分页查询数据之前先清理分页缓存。
原因:
PageHelper 方法使用了静态的 ThreadLocal 参数,分页参数和线程是绑定的。
只要你可以保证在 PageHelper 方法调用后紧跟 MyBatis 查询方法,这就是安全的。因为 PageHelper 在 finally 代码段中自动清除了 ThreadLocal 存储的对象。
线程中start的page 不能保证线程在当前执行退出时清理完page变量
复现:
在执行PageHelper.start(pageNum,pageSize);方法后,参数page变量,如xx!=null,直接返回XX,则page没有被消费,这个参数就会一直保留在这个线程上。当这个线程再次被使用时,如果接下来执行其它sql,就可能导致不该分页的方法去消费这个分页参数,这就产生了莫名其妙的分页。
如果PageHelper.start(pageNum,pageSize);之后的方法加了缓存,也会有这个问题。
解决方法:
1.使用参数方式是极其安全的
2.保证在 PageHelper 方法调用后紧跟 MyBatis 查询方法,必须保证分页和查询同时有效。
3.调PageHelper.clearPage();
MybatisPlus 和 PageHelper插件都通过使用threadLocal 来实现分页功能
ThreadLocal是一个线程内部的数据存储类,通过它可以在当前线程存储数据,其内部维护了一个ThreadLocalMap,其内部Entity继承WeakReference,key是当前threadLocal对象。
更多推荐
所有评论(0)