DBeaver能导入千万级数据，但默认配置（单线程、批次200、提交间隔10000）会导致网络往返过多、事务频繁、CPU单核满载，极易因内存溢出、连接重置或类型转换失败而中断；必须同步调优最大线程数、批次大小、提交间隔，并匹配目标库JDBC参数（如MySQL的rewriteBatchedStatements=true、ClickHouse的compress=false等），否则界面设置无效。
直接上结论：DBeaver 能导入千万级数据，但默认配置下必然卡死或超时；必须手动调 最大线程数、批次大小、提交间隔 三项，且要配合目标库连接参数（如 ClickHouse 的 compress=false 或 MySQL 的 max_allowed_packet）一起改，否则光调界面参数没用。
为什么默认设置导千万行会失败
不是 DBeaver 不行，是它默认按“小批量校验型导入”设计的：单线程、每 200 行一批、每 10000 行提交一次。对千万行来说，就是 5 万次网络往返 + 数千次事务提交 + CPU 单核满载跑数小时——中间任意环节（内存不足、连接超时、字段类型不匹配）都会中断，且错误堆在最后才报。
- 常见错误现象：
java.lang.OutOfMemoryError: Java heap space（客户端内存溢出）、Connection reset（服务端主动断连）、预览页正常但导入中途报“无法将字符串转换为数字” - 根本原因不在文件本身，而在 DBeaver 把整份 CSV 加载进内存做类型推断 + 分块写入时，缓冲区和 JDBC 参数没对齐
- 特别注意：Excel 文件必须先转
CSV UTF-8，DBeaver 原生不解析.xlsx，强行选会静默失败
必须改的三个核心参数位置
这三个参数分散在向导不同页面，容易漏设：
-
最大线程数：右键表 → 导入数据 → “输出设置”页 → 找“最大线程数”。值设为 CPU 物理核数 × 1.5（如 8 核设 12），但不能超过目标库max_connections值，否则直接报Too many connections -
批次大小：同一向导的“设置”页 → “批量大小”。MySQL/PostgreSQL 建议 5000–10000；ClickHouse 建议 10000–50000（需同步调大 JDBC 的max_block_size）；含 BLOB 字段的行建议 ≤500 -
提交间隔：同页勾选“使用事务”，再设“在行插入后执行提交”的数值。千万级可设为 20000–50000，但若勾了“忽略重复行”，必须 ≤10000，否则冲突检测失效
目标库连接参数不调，界面调了也白调
界面参数只控制 DBeaver 端行为，JDBC 驱动层的限制才是硬门槛。以主流库为例：
- MySQL：编辑连接 → “驱动属性” → 加
rewriteBatchedStatements=true（启用批量优化）和useServerPrepStmts=false（避免预编译开销） - ClickHouse：连接 → “驱动属性” → 必须设
compress=false（关压缩省 CPU）、socket_timeout=0（防超时）、max_block_size=1048576（匹配批次大小） - PostgreSQL：加
batchMode=on和reWriteBatchInserts=true，否则批次被拆成单条 INSERT
这些参数不填，即使界面上设了 10000 批次，实际发到库的还是 1 行 1 条。
导入前必做的三件事
跳过这三步，90% 的“导入失败”其实源于准备阶段：
- 用文本编辑器打开 CSV，确认分隔符是逗号还是制表符——Excel 另存为 CSV 有时会用分号，DBeaver 默认认逗号，不改就全塞进第一列
- 在导入向导“预览”页拉到最后几行，看日期、数字列是否解析正确；如果“2026-10-01”变成“2026/10/01”，说明日期格式没匹配，得在“列映射”里手动指定
yyyy-MM-dd - 检查目标表是否有唯一索引或外键约束；千万级导入前建议临时
ALTER TABLE xxx DISABLE KEYS（MySQL）或SET CONSTRAINTS ALL DEFERRED（PG），导完再启，否则每行都校验索引，速度归零
最易被忽略的是：DBeaver 的错误日志藏在“任务结果”面板底部，不是弹窗；而真正致命的 JDBC 连接级报错，得去“窗口 → 显示视图 → 错误日志”里翻 org.jkiss.dbeaver.data.transfer 相关条目——那里才有 socket closed 或 packet too large 的原始线索。
