batchsize本质是在吞吐量、内存占用、锁持有时间和事务安全间找平衡点；mysql建议500–1000条/批，oracle建议100–500条，postgresql可至1000–2000条，需配合rewritebatchedstatements=true等jdbc参数及事务统一控制。
控制单批次大小（batchSize）本质是在吞吐量、内存占用、锁持有时间和事务安全之间找平衡点，不是越大越好，也不是越小越稳。
batchSize 的合理取值范围
实际项目中，500–2000 是较通用的安全区间，具体取决于数据行体积、数据库类型和网络环境：
- MySQL 场景下建议 500–1000 条/批：受
max_allowed_packet限制，单条 INSERT 多值语句长度不能超限； - Oracle 建议 100–500 条/批：服务端预编译机制对 batch 支持较弱，过大易触发内部缓冲溢出；
- PostgreSQL 可放宽至 1000–2000 条：原生支持大 VALUES 列表，且 WAL 日志写入效率高；
- 若单行数据平均超 1KB（如含大文本或 JSON 字段），应主动下调 batchSize 至 200 以内，防止内存陡增。
必须配合的 JDBC 参数设置
只调 batchSize 不改连接参数，基本白忙——MySQL 尤其明显：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- URL 中启用重写：
rewriteBatchedStatements=true，否则 addBatch() 只是伪批量； - 关闭服务端预编译：
useServerPrepStmts=false，否则重写失效； - 手动控制事务：
connection.setAutoCommit(false)，所有 batch 共享一个事务，最后统一 commit； - 执行完一批后立刻调用
clearBatch()，避免后续 addBatch 累加导致 OOM 或逻辑错乱。
动态调整比固定值更可靠
静态 batchSize 在数据不均时容易失衡。可按以下逻辑做轻量级自适应：
- 首次尝试用 800 条/批；
- 若某批 executeBatch() 报
Packets larger than max_allowed_packet，立即降为 400 并记录告警； - 若连续 3 批耗时低于 50ms，可试探性提升至 1000；
- 监控每批返回的更新行数，若大量为 0，说明存在脏数据或条件过滤过严，需前置校验而非硬调 batchSize。
事务边界必须独立于 batch 边界
常见误区是“一批一提交”，这会让日志刷盘成为瓶颈。正确做法是：
- 一个业务逻辑单元（如导入一个 Excel 文件）包裹在一个事务里；
- 每 500–1000 条调一次 executeBatch()，但不 commit；
- 全部 batch 执行完再 commit()；
- 若中途出错（比如主键冲突或字段超长），调用 rollback() 回滚整个事务，保证原子性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
