SpringBoot+MyBatis查询MySQL首次仅返回1条、二次查询返回全量数据问题

核心排查方向（按优先级从高到低） #

1. 优先排查分页插件线程参数污染 #

这是符合你现象的最高概率根因：
如果你的项目引入了PageHelper等分页插件，由于你使用的是线程池（日志显示pool-6-thread-1为复用线程），若上一个使用该线程的业务逻辑调用了PageHelper.startPage(1,1)后没有正常清理线程本地变量，就会导致：

• 第一次执行查询时，分页插件自动给SQL拼接LIMIT 1，所以只返回1条结果
• 第一次查询结束后，分页插件会自动清理线程本地的分页参数，第二次查询无额外拼接，返回全部符合条件的数据

验证&解决方法：

• 临时移除MyBatis配置中的分页插件，重测验证问题是否消失
• 确认是分页插件问题后，做如下修复：
  • 每次使用PageHelper分页查询后，主动调用PageHelper.clearPage()清理参数
  • 配置分页插件参数supportMethodsArguments=false，禁止从线程变量透传分页参数
  • 在你的querySumProceedsUnAccountList方法执行前，主动调用PageHelper.clearPage()做兜底清理

2. 验证MySQL侧实际执行的SQL #

开启MySQL的通用查询日志（general_log），对比两次请求实际执行的SQL内容：

-- 临时开启general_log（测试环境操作，生产勿用）
SET GLOBAL general_log = 'ON';
SET GLOBAL log_output = 'TABLE';
-- 执行测试后查询日志
SELECT argument FROM mysql.general_log WHERE command_type = 'Query' AND argument LIKE '%payment_proceeds_current%' ORDER BY event_time DESC;

如果第一次查询的SQL尾部带LIMIT 1，即可完全确认是应用层（分页插件/自定义拦截器）拼接了额外条件。

3. 排查JDBC驱动与配置问题 #

• 检查你的JDBC连接参数是否配置了useCursorFetch=true且defaultFetchSize=1，该配置会导致JDBC分批拉取结果，若MyBatis结果处理逻辑异常会导致只拿到首批数据
• 升级MySQL Connector/J驱动到最新稳定版，排除驱动本身的结果解析BUG

4. 事务与隔离级别排查 #

你当前方法的事务传播级别是REQUIRES_NEW，同事务内的两次查询默认在MySQL RR隔离级别下为快照读，理论上不会出现结果不一致的情况，除非有其他事务在两次查询间隔刚好提交了所有匹配数据（但你的两次查询间隔仅1ms，该概率极低），可临时调整方法为非事务方法测试验证。

内容的提问来源于stack exchange，提问作者Jerins