DBeaver 数据迁移实操手册按 3 个阶段走 9 个动作把 CSV 灌库一次做稳【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaverCSV 导入跑到一半弹窗告诉你第 1500 行解析失败主键冲突直接中断或者整列中文进了库就变问号。说实话这类故障八成出在导入开始之前——编码没确认、分隔符猜错了、主键冲突策略没选对数据迁移才会在最忙的时候给你下马威。DBeaver 数据导入本身不复杂咱们按导入前、导入中、导入后三个阶段走一遍9 个动作做完基本能覆盖绝大多数坑。导入前把数据体检做完再动手先确认 CSV 编码和分隔符再谈导入这是踩坑最多的第一步。拿file -i data.csv看一眼有没有 BOM 标记没有 BOM 又明显是 Windows 出来的文件大概率是 GBK——编码选错整列中文直接变乱码而且不报错只会静静地灌进错误字符。另外把分隔符、引号字符、空值占位符很多业务 CSV 用-或N/A当空值和表头是否首行这四件事在导入向导的 CSV 配置页里逐项确认DBeaver 的 CSV 导入器DataImporterCSV就是靠这组参数解析文件的默认值只对逗号加双引号这种教科书 CSV友好。把外键表的顺序按依赖排好多表数据迁移先想清楚顺序字典表、主表在前子表在后。原因是子表引用的主键值必须在父表已经存在否则外键约束会让整批插入反复失败你还会怀疑是数据坏了。顺序对了后面才轮得到主键冲突时该选哪种覆盖策略的问题。先跑 100 行试导入别直接开全量。在导入向导里限制只导入前 100 行走完全流程。目的不是验证数据对——100 行里未必含脏数据——而是把映射、类型、冲突策略这些配置错误提前暴露出来错误来得快、清理得也快不会污染生产库。导入中配置、执行与盯进度盯住列映射的类型推断结果CSV 导入时源列初始都按varchar处理导入器会读前 100 行采样来推断每列的真实类型。采样行里混进一个空值或N/A整列就可能被拉成字符串到库里才发现数字列存的是文本后面所有计算、索引全受影响。所以映射步骤里逐列过一遍关键字段该强制int、decimal、timestamp的手动改。日期字段尤其敏感源文件写MM/dd/yyyy、目标按 ISO 解析要么在源文件里统一格式要么先按字符串落表再转别赌解析器猜得对。把主键冲突策略先定成忽略再定最终方案第一次跑就用忽略冲突模式重跑一遍看重复的行数有多大规模。重复少维持忽略即可重复多且业务上需要更新再改成 upsert 覆盖并且建议只覆盖必要列——整行覆盖会把没变化的行也标记成已修改白白产生写放大。策略不是越聪明越好和数据的重复模式匹配才好。把批次提交调大再开跑默认逐行提交在百万级数据下会非常慢每次提交都有一次日志刷盘开销。调大批次大小让事务内一次写入几百到几千行吞吐能上一个数量级这也是大批量数据迁移时 JVM 内存和数据库日志压力之间的平衡点。别只盯进度条盯错误列表⚠️ DBeaver 的错误处理是收集模式DataTransferStateplugins/org.jkiss.dbeaver.data.transfer/src/org/jkiss/dbeaver/tools/transfer/DataTransferState.java会累积所有加载异常并继续跑最后统一报告。进度条 100% 不代表零失败结束后的错误统计和具体条目才是结论。坏行比例很低就先记下来回头补比例偏高说明源文件有系统性问题回到编码和分隔符那一步重查。导入后验证、回滚与经验沉淀核对行数与抽样校验行数先对COUNT(*)对比源文件行数和目标表行数不一致就按错误列表逐条核。再抽三个脏数据重灾区——日期、金额、中文文本——人工翻几行确认没串位、没丢精度。这一步省了错误会潜伏到业务报表里才被发现排查成本翻十倍。准备好这一批的回滚方案生产库导入前记下目标表当前行数把准备覆盖的主键值备份出去。真发现策略选错按备份的主键集合删掉这批再重导比全库回滚快得多也更可控。把这次的配置沉淀成模板把这次 DBeaver 数据导入用过的参数——编码、分隔符、空值字符串、列类型覆盖、冲突策略、批次大小——整份记进团队的数据迁移手册。下次换数据源只改文件路径和列映射几分钟就能重新跑起来。现在就可以打开导入向导挑个 20 行的 CSV按上面的顺序把 9 个动作走一遍。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DBeaver 数据迁移实操手册：按 3 个阶段走 9 个动作，把 CSV 灌库一次做稳
DBeaver 数据迁移实操手册按 3 个阶段走 9 个动作把 CSV 灌库一次做稳【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaverCSV 导入跑到一半弹窗告诉你第 1500 行解析失败主键冲突直接中断或者整列中文进了库就变问号。说实话这类故障八成出在导入开始之前——编码没确认、分隔符猜错了、主键冲突策略没选对数据迁移才会在最忙的时候给你下马威。DBeaver 数据导入本身不复杂咱们按导入前、导入中、导入后三个阶段走一遍9 个动作做完基本能覆盖绝大多数坑。导入前把数据体检做完再动手先确认 CSV 编码和分隔符再谈导入这是踩坑最多的第一步。拿file -i data.csv看一眼有没有 BOM 标记没有 BOM 又明显是 Windows 出来的文件大概率是 GBK——编码选错整列中文直接变乱码而且不报错只会静静地灌进错误字符。另外把分隔符、引号字符、空值占位符很多业务 CSV 用-或N/A当空值和表头是否首行这四件事在导入向导的 CSV 配置页里逐项确认DBeaver 的 CSV 导入器DataImporterCSV就是靠这组参数解析文件的默认值只对逗号加双引号这种教科书 CSV友好。把外键表的顺序按依赖排好多表数据迁移先想清楚顺序字典表、主表在前子表在后。原因是子表引用的主键值必须在父表已经存在否则外键约束会让整批插入反复失败你还会怀疑是数据坏了。顺序对了后面才轮得到主键冲突时该选哪种覆盖策略的问题。先跑 100 行试导入别直接开全量。在导入向导里限制只导入前 100 行走完全流程。目的不是验证数据对——100 行里未必含脏数据——而是把映射、类型、冲突策略这些配置错误提前暴露出来错误来得快、清理得也快不会污染生产库。导入中配置、执行与盯进度盯住列映射的类型推断结果CSV 导入时源列初始都按varchar处理导入器会读前 100 行采样来推断每列的真实类型。采样行里混进一个空值或N/A整列就可能被拉成字符串到库里才发现数字列存的是文本后面所有计算、索引全受影响。所以映射步骤里逐列过一遍关键字段该强制int、decimal、timestamp的手动改。日期字段尤其敏感源文件写MM/dd/yyyy、目标按 ISO 解析要么在源文件里统一格式要么先按字符串落表再转别赌解析器猜得对。把主键冲突策略先定成忽略再定最终方案第一次跑就用忽略冲突模式重跑一遍看重复的行数有多大规模。重复少维持忽略即可重复多且业务上需要更新再改成 upsert 覆盖并且建议只覆盖必要列——整行覆盖会把没变化的行也标记成已修改白白产生写放大。策略不是越聪明越好和数据的重复模式匹配才好。把批次提交调大再开跑默认逐行提交在百万级数据下会非常慢每次提交都有一次日志刷盘开销。调大批次大小让事务内一次写入几百到几千行吞吐能上一个数量级这也是大批量数据迁移时 JVM 内存和数据库日志压力之间的平衡点。别只盯进度条盯错误列表⚠️ DBeaver 的错误处理是收集模式DataTransferStateplugins/org.jkiss.dbeaver.data.transfer/src/org/jkiss/dbeaver/tools/transfer/DataTransferState.java会累积所有加载异常并继续跑最后统一报告。进度条 100% 不代表零失败结束后的错误统计和具体条目才是结论。坏行比例很低就先记下来回头补比例偏高说明源文件有系统性问题回到编码和分隔符那一步重查。导入后验证、回滚与经验沉淀核对行数与抽样校验行数先对COUNT(*)对比源文件行数和目标表行数不一致就按错误列表逐条核。再抽三个脏数据重灾区——日期、金额、中文文本——人工翻几行确认没串位、没丢精度。这一步省了错误会潜伏到业务报表里才被发现排查成本翻十倍。准备好这一批的回滚方案生产库导入前记下目标表当前行数把准备覆盖的主键值备份出去。真发现策略选错按备份的主键集合删掉这批再重导比全库回滚快得多也更可控。把这次的配置沉淀成模板把这次 DBeaver 数据导入用过的参数——编码、分隔符、空值字符串、列类型覆盖、冲突策略、批次大小——整份记进团队的数据迁移手册。下次换数据源只改文件路径和列映射几分钟就能重新跑起来。现在就可以打开导入向导挑个 20 行的 CSV按上面的顺序把 9 个动作走一遍。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考