DBeaver导入中断后无法直接续传，因其无内置持久化断点机制；需用“执行Script”替代向导实现类断点效果，或对CSV预处理分块导入并启用错误跳过。
导入中断后不能直接“继续”，DBeaver默认不保存断点状态
直接关掉导入窗口或崩溃后重开，DBeaver不会记住你导到第几行——它没有内置的持久化断点机制。所谓“断点续传”，实际是靠外部策略绕过限制，不是点个按钮就能接上。核心原因在于：DBeaver的数据传输任务（DataTransferState）生命周期绑定在当前向导实例中，一旦退出，所有进度、已处理行数、事务上下文全部丢失。
用“执行Script”替代导入向导，实现类断点效果
这是最稳定、实测有效的方案，尤其适合大SQL文件（>50MB）。它不走数据传输模块，而是调用数据库原生命令流式执行，天然支持部分失败后的手动续导。
- 右键目标数据库 → 执行Script（不是“导入数据”）
- 勾选
Continue script execution on error（关键！此选项控制是否跳过单条语句错误） - 若文件含多条INSERT，且某条失败，后续语句仍会执行；失败位置可通过日志中的行号定位
- 手动续导时，用文本编辑器删掉已成功执行的部分（注意保留完整语句边界），再重新执行剩余内容
CSV导入中途失败？靠预处理+分块+错误跳过组合应对
CSV无法真正“续导”，但可以极大降低重导成本。重点不是恢复进度，而是让重试变得轻量可控。
- 导入前用命令行切分大CSV：
split -l 10000 big.csv chunk_，生成多个万行小文件 - 每个小文件单独导入，启用
遇到错误时继续并设最大跳过错误数（如10） - 导入失败后，只重试那个出错的
chunk_*文件，而非全量重来 - 注意：确保目标表有主键或唯一约束，否则重复导入可能造成脏数据
别信“智能断点续传”，小心SET IDENTITY_INSERT这类隐式操作
某些文档提到的“智能断点续传”功能，实际只存在于特定场景（如SQL脚本执行中自动标记已成功语句），且不适用于标准CSV/Excel导入流程。更危险的是，像SQL Server这类数据库，DBeaver会在导入前自动执行 SET IDENTITY_INSERT ON，而该操作需要 ALTER 权限——如果你中途重试，权限缺失会导致第二次导入直接卡在第一步，报错却和原始问题无关。
真正容易被忽略的点是：断点续传的前提是“幂等性”，但DBeaver的导入行为本身不保证幂等。同一份CSV反复导入，可能因约束检查时机、事务隔离级别或自增列处理逻辑不同，产生不可预测的结果。
