rewriteBatchedStatements=true是MySQL批量插入性能跃升的关键开关，开启后驱动将多条INSERT合并为单条多值语句（如INSERT INTO t VALUES (?),(?),(?)），避免默认“伪批量”下逐条网络请求导致的高延迟。
rewriteBatchedStatements=true 是 MySQL 批量插入性能跃升的关键开关，不加它，Java 里的 addBatch() 和 executeBatch() 基本等于白写。
为什么开了 rewriteBatchedStatements 才算真批量
MySQL JDBC 驱动默认行为是“伪批量”：哪怕你调用 addBatch() 100 次，executeBatch() 仍会拆成 100 次独立的 INSERT INTO t VALUES (?) 网络请求。每条都走完整 TCP 往返、服务端 SQL 解析、日志刷盘流程。
开启 rewriteBatchedStatements=true 后，驱动在客户端直接重写语句：
- 对
INSERT：合并为INSERT INTO t VALUES (?),(?),(?)单条多值语句 - 对
UPDATE/DELETE：拼成UPDATE t SET x=1 WHERE id=1; UPDATE t SET x=2 WHERE id=2;（需配合allowMultiQueries=true） - 仅当批大小 > 3 时才触发重写（源码硬编码阈值），太小的 batch 不值得合并
必须配齐的三个连接参数
单开 rewriteBatchedStatements=true 效果打折，容易踩内存或语法错误坑。这三项要一起上：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
rewriteBatchedStatements=true：启用客户端语句重写 -
useServerPrepStmts=true：让 MySQL 服务端真正预编译，避免每次重写后都重新解析 -
cachePrepStmts=true：缓存 PreparedStatement 对象，减少反复创建开销
漏掉任意一个，实测吞吐可能只提升 2–3 倍；三者齐备，1000 条 INSERT 的平均耗时可从 12s 降到 2.5s 左右（实测环境：MySQL 8.0 + Connector/J 8.0.33）。
MyBatis-Plus 的 saveBatch 为什么默认不快
MyBatis-Plus 的 saveBatch() 底层确实调用了 addBatch() 和 executeBatch()，但它无法绕过 JDBC 驱动的默认行为。也就是说：
- 没配
rewriteBatchedStatements=true→ 还是逐条发 SQL - 批大小由
batchSize参数控制（如saveBatch(list, 1000)），但驱动仍按自己逻辑决定是否重写 - 如果实体字段含
null或特殊类型（如LocalDateTime），重写后可能触发SQLSyntaxErrorException，需确认驱动版本兼容性（8.0.29+ 更稳）
容易被忽略的边界和陷阱
这个参数不是万能银弹，几个关键点常被跳过：
- 只对
PreparedStatement生效，Statement不支持重写 - 重写后的 SQL 总长度受
maxAllowedPacket限制，超长会报Packets larger than max_allowed_packet bytes，需同步调大 MySQL 配置 - 事务内使用时，失败会回滚整批，错误定位困难；建议配合
continueBatchOnError=false（默认）并捕获BatchUpdateException查具体哪条出错 - 云数据库（如阿里云 RDS）部分版本默认禁用多语句，需确认
allowMultiQueries是否被服务端策略拦截
最常被漏掉的是：以为加了参数就万事大吉，却没验证实际发送到 MySQL 的 SQL 形态——用 general_log 或代理层（如 ProxySQL）抓包看真实语句，才是唯一可信的判断方式。
