SQL Server存储过程+Spring Batch处理120万行过慢，求优化方案

优先解决存储过程本身的性能瓶颈 #

你在SSMS直接执行basic_json_normalization_full也慢，说明核心性能问题出在存储过程逻辑上，先优化这个比调整Spring Batch调用方式更有效：

• 检查JSON解析效率：SQL Server的OPENJSON等函数是否用到合适的索引？比如给原始表的JSON字段创建JSON索引，或者把常用的JSON属性提取为计算列并建立普通索引。
• 优化批量写入：如果存储过程是逐行插入目标表，改成INSERT ... SELECT这类批量插入方式，或者添加TABLOCK提示提升写入性能。
• 分析执行计划：在SSMS里查看存储过程的执行计划，定位全表扫描、高成本键查找等操作，针对性添加索引。
• 拆分大事务：如果存储过程用了覆盖全量数据的大事务，拆分成小事务减少日志压力，避免长时间锁表。

Spring Batch层面的优化（存储过程优化后） #

当存储过程本身性能达标后，可通过Spring Batch的特性进一步提速：

1. 分区处理（Partitioning） #

把120万条数据拆分为多个独立数据段，并行处理：

• 按ID范围、创建时间区间等字段拆分数据，给存储过程新增分区参数（比如@startId、@endId），让它只处理对应区间的数据。
• 配置PartitionedStep，用SimplePartitioner自定义分区规则，比如分成20个分区，每个分区处理6万条数据，各分区并行执行。

2. 多线程Step（Multi-threaded Step） #

如果存储过程处理不同数据段时无锁冲突，可启用多线程并行调用：

• 配置ThreadPoolTaskExecutor，给Step指定task-executor属性，让多个线程同时调用存储过程处理不同数据块。
• 注意控制线程数，一般不要超过数据库CPU核心数的2倍，避免给SQL Server造成资源过载。

3. 增量处理（若业务允许） #

如果不是每次都需要处理全量数据，改成增量模式：

• 记录上次处理的最大ID或最新时间戳，每次只处理新增数据，大幅减少单次处理的数据量。

关键注意事项 #

• 并行处理时要严格划分数据范围，避免重叠或遗漏，保证数据一致性。
• 监控SQL Server的CPU、内存、磁盘IO使用率，若并行后出现资源瓶颈，及时调整线程数或分区数量。

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