SpringBatch读取MySQL触发filesort导致分页查询性能低下问题

该问题同时涉及Spring Batch组件配置、MySQL查询优化两个技术范畴，不属于单一技术栈问题。

• 业务场景：使用Spring Batch的JdbcPagingItemReader组件读取MySQL数据库数据，待读取总数据量接近100万条
• 参数配置：fetchSize与pageSize参数均设置为10000
• 查询逻辑：执行的SQL包含多表关联、group by逻辑，所有关联ID字段均已建立索引，排序规则基于主键字段

• 每批次10000条数据的读取速度极慢
• 通过explain分析SQL执行计划发现：即使相关字段全部建立索引，由于查询包含主键排序逻辑，MySQL内部仍使用filesort机制执行排序

该场景属于Spring Batch批量读MySQL的高频常见问题，大量开发者都遇到过同类表现，核心原因和可落地优化方案如下：

核心原因 #

1. MySQL侧：多表关联+group by场景下，查询优化器会自主判断执行成本，当优化器认为先完成关联、分组，再走filesort的成本低于沿主键索引顺序扫描关联的成本时，就会主动选择filesort执行路径，和主键是否建索引没有必然联系。如果分页排序的主键不是驱动表主键，关联、分组生成的临时表无法复用主键索引，也会触发额外排序。
2. Spring Batch配置侧：MySQL JDBC驱动默认行为是将全量查询结果拉取到客户端内存，单独设置fetchSize不会生效，必须在JDBC连接串中配置useCursorFetch=true参数后，fetchSize的流式读取配置才会起作用，配置不生效时大结果集传输、内存加载都会拖慢读取速度。另外10000的pageSize设置偏大，会提升单次查询的排序、数据传输开销。

优化方案 #

• SQL改写：调整查询逻辑，先对驱动表做单表主键排序分页，拿到单批次的主键ID集合后，再关联其他表做分组、聚合计算，避免在全量关联结果集上触发排序
• 配置调整：将pageSize下调到1000-2000区间，JDBC连接串增加useCursorFetch=true参数，确保fetchSize配置生效
• 校验逻辑：打印JdbcPagingItemReader自动生成的完整分页SQL，确认分页排序键是驱动表的主键，不要用关联表字段作为分页排序依据

由于当前未提供具体SQL语句、表结构和完整执行计划，以上为同类场景下的通用优化方向，实际排查时可以先单独执行打印出的分页SQL验证执行计划，再做针对性调整。

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