不能只dump一次，因易导致锁表、阻塞、中断等故障；须采用“全量打底+增量追平”策略，配合日志解析、自动类型映射、批量加载优化及行级一致性校验。

全量+增量双轨迁移：为什么不能只 dump 一次？

大表一次性导出再导入，看似简单，实则极易卡在中间环节——源库锁表、目标库写入阻塞、网络中断重试失败，最后发现迁移花了三天，业务停了六小时。真正可行的方案是“全量打底 + 增量追平”，即先快速导出历史快照，再实时捕获变更持续同步，最终在短窗口内切流。

• mysqldump 或 pg_dump 只适合全量阶段；但必须加 --single-transaction（MySQL）或 -Fc（PostgreSQL）保证一致性，否则可能导出半截事务数据
• 增量依赖日志解析：binlog（MySQL）、WAL（PostgreSQL）、redo log（Oracle），不是所有数据库都开放读取权限，比如某些云厂商 RDS 默认关闭 binlog 二进制日志
• 工具链要能衔接：例如用 Debezium 解析 binlog 输出 Kafka，再用 Flink CDC 写入目标库，中间任何一环断开，偏移量（offset）就丢失，导致重复或漏数据

字段类型与 SQL 语法自动映射：别手动改 CREATE TABLE

把 MySQL 的 VARCHAR(255) 直接当 PostgreSQL 的 VARCHAR(255) 用？危险。PostgreSQL 实际按 text 处理更稳妥；Oracle 的 NUMBER(10,2) 到 MySQL 的 DECIMAL(10,2) 看似一样，但精度舍入规则不同，财务类数据可能出偏差。

• 不要手写 DDL 脚本迁移表结构——人工映射漏项率高，尤其 DEFAULT、CHECK、GENERATED 列等冷门特性
• 优先用带语义识别能力的工具：如金仓 KDTS、AWS DMS 的表映射规则引擎，能自动处理 TIMESTAMP 时区行为、JSON 类型兼容性、甚至 auto_increment → serial 的主键生成逻辑转换
• 注意 NULL 行为差异：MySQL 允许 NOT NULL 字段插入空字符串，PostgreSQL 不允许；迁移后若没做数据清洗，INSERT 会直接报错 ERROR: null value in column

批量加载性能瓶颈在哪？绕开 INSERT 单条提交

用 ORM 或 JDBC 逐行 INSERT 导千万级数据？CPU 和网络早烧穿了。瓶颈不在磁盘，而在事务开销、日志刷盘、索引实时更新这三重枷锁。

• 目标库加载前务必禁用索引和外键：ALTER TABLE t1 DISABLE KEYS（MySQL）、SET CONSTRAINTS ALL DEFERRED（PostgreSQL），加载完再重建，速度可提升 5–10 倍
• 用原生命令替代通用驱动：mysqlimport 比 LOAD DATA INFILE 更可控；PostgreSQL 用 copy 命令而非 INSERT ... VALUES，吞吐量差一个数量级
• 分批次大小有讲究：MySQL 批量 INSERT 控制在 1000–5000 行/批；PostgreSQL copy 单次建议 ≤ 10MB 数据，太大易 OOM，太小则事务开销占比过高

数据一致性校验不是“比行数”：怎么确认真没丢？

迁移后 SELECT COUNT(*) 两边一样，不代表数据一致。空格、换行符、时区偏移、浮点精度、LOB 截断……这些肉眼不可见的差异，才是线上事故的伏笔。

• 行级校验必须抽样：对关键表按 id % 1000 = 0 抽千分之一行，用 md5(concat_ws('|', col1, col2, ...)) 生成哈希比对，比全量扫描快且可靠
• 避免跨库时间函数陷阱：NOW() 在 MySQL 和 PostgreSQL 中默认时区可能不同，校验时间字段时统一转成 UTC 再比对
• LOB（大对象）单独处理：MySQL 的 MEDIUMTEXT 导入 PostgreSQL 的 text 时，若含特殊控制字符，可能被截断或转义失败，需额外用 HEX() 或 Base64 编码比对原始字节

异构迁移最耗神的从来不是技术实现，而是“哪里不一致”这种问题永远藏在下一层抽象之下——日志偏移量对不上、字符集隐式转换、甚至某个触发器在目标库压根不生效。留出足够验证时间，比压缩迁移窗口更重要。