DBeaver导出功能不支持断点续传，因其采用流式生成+单次写入逻辑，无偏移标记、校验机制或状态记录；中断后文件不完整，须删除重做，推荐改用mysqldump、pg_dump或SQL原生命令分批导出。
导出中断后无法续传，必须重做
DBeaver 的 导出数据 功能不支持断点续传。一旦导出过程因网络中断、内存不足、目标磁盘满或手动取消而中止，已写入的文件（如 CSV、SQL）是不完整且不可靠的，没有内部状态记录或校验机制来判断“导出到第几行”。强行用部分文件导入，大概率触发主键冲突、数据截断或乱码。
为什么 DBeaver 不提供续传能力
根本原因在于它的导出逻辑是「流式生成 + 单次写入」，而非分块加校验的可靠传输协议：
-
DataTransferWizard在执行时不会预计算总行数，也不为每批数据生成唯一标识或偏移标记 - 导出目标为文件时，DBeaver 依赖底层 Java I/O 流直接 write，不维护 offset 日志
- 导出目标为数据库时，走的是 JDBC
PreparedStatement批量插入，失败即回滚整个批次（若启用事务），无法跳过已成功行 - 官方插件目录
plugins/org.jkiss.dbeaver.data.transfer/中无 checkpoint 或 resume 相关类
大文件导出更稳的替代做法
面对百万级以上数据导出，绕过 GUI 向导、改用可控性更强的方式才是实际解法：
- 对 MySQL/PostgreSQL 等支持原生命令的库，优先用
mysqldump或pg_dump，它们自带--where、--skip-triggers和分卷参数（如-F c -v -f backup.dump） - 在 DBeaver 中写 SQL 导出：用
SELECT ... INTO OUTFILE（MySQL）或COPY (SELECT ...) TO 'path'（PostgreSQL），路径需为数据库服务端可写位置 - 拆表导出：右键单表 →
导出数据→ 勾选WHERE 条件，例如id BETWEEN 1 AND 100000，分多批次手动执行 - 禁用「打开新连接，使用事务」选项：该选项会把全量 INSERT 包进一个事务，极易因超时或锁表失败；改为单条提交或批量提交（设 Batch size = 1000）
中断后检查与清理要点
导出中断不是结束，而是要立刻确认三件事：
- 检查目标路径下生成的文件是否以
.part、.tmp或无扩展名结尾——这类文件一律删除，不可重命名复用 - 若导出目标是另一数据库且勾选了「使用事务」，刷新目标表，确认无脏数据残留（DBeaver 中断时未必能干净 rollback）
- 查看 DBeaver 日志：
Help → Show Log Viewer，搜索ERROR或InterruptedException，定位是 JDBC 驱动层报错（如EOFException），还是本地磁盘 I/O 失败
真正影响效率的从来不是“怎么续”，而是“怎么避免中断”——调低 Batch size、关掉实时预览、确保目标路径有足够空间且非网络挂载盘，比期待续传现实得多。
