如何将SQL从一种数据库迁移到另一种？

本文目录导读：

1. 第一阶段：评估与规划
2. 第二阶段：选择合适的工具
3. 第三阶段：核心步骤（以“手动+脚本”为例，理解原理）
4. 第四阶段：常见“坑”与对策
5. 总结操作建议

将SQL（数据库）从一种系统迁移到另一种（例如从MySQL到PostgreSQL，或从Oracle到SQL Server）是一个复杂的工程，通常被称为数据库迁移，成功的关键在于充分的前期分析、数据类型的精确映射、以及全面的测试。

以下是一个分阶段的通用方法论和具体操作步骤：

第一阶段：评估与规划

在迁移前,必须回答以下问题：

1. 源和目标是什么？ 明确源数据库、版本和目标数据库、版本。
2. 迁移什么？ 只迁移数据（结构和数据），还是包括存储过程、函数、触发器、视图等数据库对象？是否要迁移应用程序连接？
3. 停机时间要求？ 允许完全停机（最简单），还是需要零停机（需要CDC等技术）？
4. 数据量有多大？ 几GB还是几TB？这决定了是使用命令行工具还是图形化ETL工具。

第二阶段：选择合适的工具

根据预算和复杂度,有三种主要路径：

使用官方或第三方迁移工具（推荐，最简单）

• 最推荐： AWS DMS、Azure DMS、Google Database Migration Service，这些云原生工具能自动处理数据类型映射和模式转换,且支持持续同步。
• 开源工具：
  • pgloader： 从MySQL、SQLite、MS SQL等迁移到PostgreSQL,速度极快且自动处理类型映射。
  • Oracle SQL Developer： 免费的Oracle迁移工具，支持到MySQL、PostgreSQL等。
  • SQL Server Migration Assistant (SSMA)： 微软官方工具，用于从Oracle、MySQL、Sybase等迁移到SQL Server/Azure。
• 图形化工具： Navicat、DBeaver、HeidiSQL 提供的数据传输功能。

使用ETL工具（适用于复杂转换）

• Talend Open Studio、Pentaho Data Integration、Apache Nifi：适合需要复杂数据转换、清洗、或需要从多个源汇集数据到单一目标的情况。

手动导出/导入（适用于小数据量或测试）

• 使用数据库自带的Dump/Export工具导出SQL文件,然后手动或通过脚本修改兼容性后再导入。

第三阶段：核心步骤（以“手动+脚本”为例，理解原理）

步骤1：模式（Schema）迁移

这是最棘手的部分,因为不同数据库的SQL方言和数据类型不同。

• 数据类型映射： 这是最常见的“坑”。
  • MySQL的TINYINT（1字节） → PostgreSQL的SMALLINT或BOOLEAN（取决于语义）。
  • MySQL的DATETIME → PostgreSQL的TIMESTAMP（无时区）。
  • Oracle的NUMBER(p,s) → SQL Server的DECIMAL(p,s)。
  • MySQL的AUTO_INCREMENT → PostgreSQL的SERIAL或GENERATED AS IDENTITY。
• 索引和约束： 语法差异。MySQL的FULLTEXT索引在PostgreSQL是GIN索引，唯一约束、主键、外键写法可能不同。
• SQL函数与存储过程： 这是最消耗精力的部分。
  • MySQL的IFNULL() → SQL Server的ISNULL() → PostgreSQL的COALESCE()。
  • Oracle的DECODE() → CASE WHEN。
  • 存储过程语言完全不同（PL/SQL vs T-SQL vs PL/pgSQL）,需要逐句重写或使用工具转换。

操作： 使用工具（如SQLines、ora2pg）自动转换DDL脚本,然后手动修复错误。

步骤2：数据迁移

• 导出：
  • 使用原生工具导出为CSV、JSON、或SQL INSERT语句。强烈建议导出为通用文本格式（如CSV），而非特定数据库的dump文件,因为后者可能不兼容。
  • 注意处理特殊字符（引号、换行符）、NULL值（不同数据库表示不同，如\N vs NULL）、和编码（统一为UTF-8）。
• 导入：
  • 使用目标数据库的COPY命令（PostgreSQL）、BULK INSERT（SQL Server）、LOAD DATA（MySQL），这些比逐条INSERT语句快成百上千倍。
  • 关闭触发器和约束检查以加速导入,导入后再重建。
  • 使用大事务或分批提交（例如每1000行提交一次）,避免事务日志爆满。

步骤3：迁移应用程序代码

• 连接字符串： 修改所有应用的数据库连接字符串（驱动类型、URL、用户名、密码）。
• SQL查询： 检查应用代码中的硬编码SQL，特别是：
  • 分页： LIMIT/OFFSET（MySQL/PostgreSQL） vs TOP/OFFSET FETCH（SQL Server）。
  • 字符串拼接： CONCAT() vs
  • 日期函数： NOW() vs GETDATE() vs CURRENT_TIMESTAMP
  • 序列/自动递增： 获取最后插入ID的方式（LAST_INSERT_ID() vs SCOPE_IDENTITY() vs RETURNING）。
• ORM框架： 如果使用Hibernate、Entity Framework、Django ORM等，通常只需更换数据库方言（Dialect）和驱动,框架会自动处理大部分差异。

步骤4：验证与测试

这是最重要的一步,也是最容易忽视的。

• 数据完整性：
  • 行数比对： 检查每个表行数是否一致。
  • 校验和比对： 对关键表计算所有数据的MD5或SHA哈希并比对（如果你有工具或写脚本的话）。
  • 抽样比对： 随机抽取若干行的所有字段,人工核对。
• 功能测试：
  • 运行所有前端功能,确保增删改查正常工作。
  • 运行存储过程,检查返回结果。
  • 测试报表和BI工具连接。
• 性能基准： 迁移后运行一次性能测试（如慢查询日志），因为优化器行为不同,可能需要重建索引或调整查询。

第四阶段：常见“坑”与对策

总结操作建议

1. 不要直接迁移生产库。 先在测试环境完整跑一遍迁移流程,记录所有报错和手动修复步骤。
2. 优先使用成熟工具： 对于主流数据库对（如MySQL → PostgreSQL），pgloader 是神器，对于云迁移,使用云服务商的DMS。
3. 数据量小（<10GB）： 可以用图形化工具（Navicat）拖拽完成，数据量大（>100GB）：必须用命令行工具（pg_dump/psql、bcp）。
4. 考虑增量同步： 如果停机时间要求严格，可以先用全量迁移，然后用CDC工具（如Debezium、AWS DMS的持续复制）捕捉并应用变化,最后切换时只需短暂停机。
5. 准备回滚计划： 迁移前完整备份源数据库，并且确保切换后48小时内能快速回退到旧系统（保留旧数据库在线）。

一个实用的迷你清单（以从MySQL迁移到PostgreSQL为例）：

1. 安装 pgloader。
2. 运行：pgloader mysql://user:pass@host/source_db postgresql://user:pass@host/target_db
3. 等待完成。
4. 检查错误日志,修复少数不兼容的SQL。
5. 运行测试脚本比对行数和字段值。
6. 修改应用连接字符串。
7. 上线。

对于非常规数据库（如MongoDB → PostgreSQL）或高度定制的存储过程,建议寻求DBA或专业数据库迁移服务商的帮助。