DBeaver导入时“在行插入后执行提交”默认值常被误设为100或500，导致频繁刷日志、WAL暴涨、卡顿，实际应根据数据量（如10万行设10000）、表结构（含大字段需下调至5000）及批次大小联动配置，且须勾选“使用事务”才生效。
默认的 在行插入后执行提交 间隔是 10000 行，但很多用户实际导入时根本没改过这个值，结果发现慢得离谱——不是因为线程少，而是事务卡在“每 100 行就偷偷提交一次”这种诡异行为上。
为什么“提交策略”比线程数更容易被忽略
很多人一上来就猛调 最大线程数，却没注意：如果 在行插入后执行提交 被设成了 100 或 500，那开 8 个线程等于 8 个频繁刷日志的小工，CPU 和磁盘都在空转。DBeaver 的提交逻辑是全局生效的，哪怕你开了多线程，只要提交间隔太小，所有线程都会被强制等提交完成才能继续下一批。
- 常见错误现象：
java.sql.BatchUpdateException频发、数据库 WAL 日志暴涨、导入中途卡住十几秒不动 - 真实场景判断：打开数据库监控（如 PostgreSQL 的
pg_stat_activity），看到大量idle in transaction状态，基本就是提交太碎 - 参数差异：
在行插入后执行提交勾选后才生效；不勾选则全程用单事务（风险高，大导入失败会全滚）；勾选但数值设太小，等于自废并行能力
怎么设提交间隔才不翻车
提交间隔不是越大越好，要和你的数据量、表结构、目标库配置对齐。设太大可能触发内存溢出或事务超时；设太小又退化成串行。
- 10 万行以内：直接设
10000，够稳也够快 - 50 万～200 万行：推荐
20000，前提是目标库max_prepared_transactions（PostgreSQL）或innodb_log_file_size（MySQL）没锁死 - 含大字段（
TEXT、JSONB、BLOB）：必须往下调，5000是安全上限，否则单批事务内存占用容易爆 DBeaver 的 JVM 堆 - 开启
忽略重复行时：提交间隔不能超过5000，否则冲突检测失效，可能漏掉本该跳过的重复数据
和“批次大小”“线程数”的联动关系
这三项不是独立调优，而是一套齿轮。比如你把 批量大小 设成 5000，但 在行插入后执行提交 还是 1000，那每跑 5 批就要提交一次，实际等于每 1000 行切一次事务，前 4 批白攒了。
- 理想配比：提交间隔 ÷ 批次大小 ≈ 整数（比如提交设 20000、批次设 4000 → 每 5 批提交一次）
- PostgreSQL 用户注意：
原生 COPY 命令引擎下，在行插入后执行提交完全无效，它走的是服务端直接写文件路径，此时该选项灰显，别白折腾 - MySQL 用户注意：如果 JDBC 连接字符串里没加
rewriteBatchedStatements=true，再大的批次大小也没用，驱动照样拆成单条INSERT
最容易被忽略的点是：DBeaver 的提交策略设置藏在“设置页”，但它的生效前提是“使用事务”已勾选——这个开关在同一个页面顶部，不拉到最上面很容易漏掉。一旦没勾，所有提交相关配置都形同虚设。
