DBeaver 跨数据库数据迁移完整指南
项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver 把跑了三年的 MySQL 老库整建制搬到 PostgreSQL，或是让 Oracle 的归档表每周定时灌进 SQL Server 做分析——这两种跨数据库迁移场景，DBeaver 的「数据传输」功能都能覆盖：不写脚本、不导文件，在 GUI 里完成从选表到批量写入的全过程，还顺手支持增量同步。
🧭 动手前先分清三种迁移模式
选错模式，后面的操作全白费。先把三种模式放一起看：
| 模式 | 适用场景 | 触发方式 | 典型参数差异 |
|---|---|---|---|
| 全量搬移 | 新环境冷启动、老库整体退役 | 对表/模式右键「数据传输」一次跑完 | 批量大小、目标表已存在时如何处理（覆盖/追加/报错） |
| 增量同步 | 源库持续写入，定期追数据 | 同样的入口，但筛选条件只圈住新增/修改行 | 时间戳或自增 ID 的 WHERE 条件、调度周期 |
| 结构+数据混合 | 目标库从 0 建表，或表结构本身要改 | 向导中勾选「传输结构」，再跑数据 | 结构映射规则、字段改名、类型转换 |
本质上，三种模式走的是同一条链路：读源数据 → 在内存中做类型转换 → 批量写入目标库。区别只在于圈定数据的条件和写入策略。分清你属于哪种，后面才知道该调哪些参数。
一条主线：MySQL 整库搬到 PostgreSQL 的最快路径
下面按真实操作顺序走一遍，我们假设源是 MySQL、目标是 PostgreSQL：
- 建好两条连接。在数据库导航器中「新建连接」，分别配好 MySQL 和 PostgreSQL。这一步的关键是：目标连接要实际登录成功，而不是只填了参数——写入阶段用的是登录后的会话权限。
- 选迁移对象。在导航器展开 MySQL 库，选中要搬的表（可多选，也可选整个模式）。
- 打开迁移入口。右键 →「数据传输」，弹出迁移向导。
- 配置映射。在向导里指定目标连接，逐表检查表名与字段映射，DBeaver 默认按同名匹配并自动做类型映射；需要筛选数据时，加一个 WHERE 条件即可，比如
updated_at > '2026-01-01'。 - 执行批量写入。点下一步，确认批量大小和错误策略（跳过并记录 / 出错即停），开始执行。进度面板会实时显示已写入行数和耗时，跑完给出一份带错误明细的统计报告。
迁移向导的完整实现在 plugins/org.jkiss.dbeaver.data.transfer/，连接与元数据模型在 plugins/org.jkiss.dbeaver.model/，想细看类型映射逻辑可以从这两个模块入手。
⚙️ 按业务场景选参数：小表快搬 / 大表分片 / 增量同步
界面选项卡只是分组方式，真正该参考的是你的数据形态。三个最常见的场景：
| 场景 | 改什么 | 给什么值 | 为什么 |
|---|---|---|---|
| 小表快搬（< 10 万行） | 什么都不用改，全走默认 | 默认批量 1000 即可 | 几分钟内跑完，调参收益为负；只需确认目标表名和字段映射 |
| 大表分片（> 100 万行） | 批量大小 + 中断恢复 | 批量从 1000 起，网络空闲时试 5000~10000 | 批量太小网络往返吃掉全部收益，太大则单条失败时回滚代价高；中断后可用范围条件续传 |
| 定期增量同步 | 筛选条件 + 任务 | 用 updated_at > 上次水位 或 id > 上次最大ID 圈定数据 | 只搬变更行，任务可挂到操作系统定时任务里反复执行 |
增量同步是新手最容易踩坑的地方：过滤条件写错，要么漏数据，要么每次都全量重搬。先用手工方式跑通一次、确认水位逻辑对，再交给调度。
🚑 踩坑速查与性能调优
这几个坑出现频率最高，遇到时对照排查：
| 问题 | 常见原因 | 解法 |
|---|---|---|
| 权限不足 | 源库只有连接权没有 SELECT，目标库缺 CREATE TABLE / INSERT | 迁移前用目标账号先手动建一张小表、插一行验证 |
| 数据类型不兼容 | 位图/枚举/自定义类型在目标库没有直接对应 | 查看映射面板标红的字段，在「转换设置」里指定目标类型或转字符串 |
| 连接超时 | 迁移窗口被防火墙掐断，或跨机房带宽不够 | 调大连接超时参数；带宽是瓶颈时，加大批量比加大并发更有效 |
| 编码乱码 | 两边字符集不一致，如 latin1 进 utf8mb4 | 检查连接的 URL 参数里是否显式指定了字符集 |
几条性能建议，都是实际跑过大表后沉淀下来的：
- 批量大小用试错法：1000 → 5000 → 10000 各跑一小批，看单位时间写入行数何时开始掉头，回退到峰值前一档。
- 目标库大表先关索引：迁移前删掉二级索引和主键，数据落地后再重建，通常能快一个数量级。
- 判断瓶颈在网络还是数据库：迁移时观察网络流量，流量打满而 CPU 不高，说明该优化批量而不是加机器。
迁移完成后的质量保障 Checklist
跑完不等于完成，勾选这五项再下线源库：
- 源库与目标库逐表行数一致（带筛选条件的按同一条件分别统计）
- 抽 20 行比对关键字段，重点看金额、时间戳、长文本
- 在目标库上跑一遍核心业务的查询和写入冒烟
- 目标表的自增 ID 起点、默认值符合后续写入约定
- 本次迁移配置已保存，增量同步任务已挂上调度
回到开头那两件事：MySQL 整库搬家，按这条主线走一遍就是一两天的工作量；Oracle 归档定期进 SQL Server，把增量水位和调度定好之后就是自动的事。数据迁到一半遇到特殊场景，比如字段级转换逻辑写不进去，欢迎到项目 Issue 区直接提问。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/gitblog_00872/article/details/156320923
