MySQL到PG迁移指南：CI流水线实现平滑切换

从MySQL迁移到PostgreSQL这事儿，表面上看好像只是换个数据库软件，但真正上手做过的人都知道，这里面的坑远比想象中要多。

AUTO_INCREMENT要改成SERIAL，IFNULL得换成COALESCE，GROUP_CONCAT对应的是string_agg，更别提分区表语法完全两码事、存储过程逻辑要一条条适配、各种索引和外键约束一个都不能错——只要有一个环节出了岔子，数据就可能丢了、查不出来、甚至根本写不进去。

今天聊的这个开源项目MySQL2PG，其核心思路是：用一套成体系的自动化测试流程，把“心跳式迁移”变成“安心迁移”。说白了，就是把大量潜在的迁移问题提前暴露在CI流水线里，而不是等到生产环境出问题才去排查。

一、167张测试表：从基础类型到业务场景的全覆盖

在create_table.sql文件中，定义了167个测试表案例，按覆盖范围分成了五大类。

第一类：基础类型与DDL语法（case_01 ~ case_40）

这一组主要覆盖数值、字符集、JSON、时间、默认值、自增、约束、生成列、保留字和命名风格等基本要素。

第二类：索引/约束与表特性（case_41 ~ case_80）

这一组把目光投向外键、全文索引、空间索引、复合主键、存储引擎、分区策略、表复制、压缩表、统计信息等更进阶的特性。

第三类：边界语法与MySQL 5.7/8.0特性（case_81 ~ case_120）

SRID、长标识符、高精度数值、多值索引、窗口函数、JSON_TABLE、锁相关语法……这些都是实践中容易踩坑的地方。

第四类：业务化建模样例（case_121 ~ case_155）

从电商、CMS、财务、社交到医疗、酒店、餐厅，这些测试表模拟了真实业务场景下的建表逻辑。

第五类：新增综合增强场景（case_156 ~ case_167）

复合外键、JSON生成列、时间类型组合、文本二进制混合、数值边界、建表方式专项——专门用来兜住那些容易被忽略的角落。

二、分区表专项测试：4种分区策略全覆盖

分区表的迁移向来是重灾区。create_comments_partition_table.sql专门拿来做这件事。

case_169_merge：RANGE分区（单分区）

基础RANGE分区示例，只有一个分区，主键必须包含分区键issue_id，存储引擎指定为InnoDB。适用于按整数范围做简单数据划分的场景。

test_partition_170_range_int：RANGE分区（多分区）

经典多分区模式，包含5个分区，范围从1000到MAXVALUE，主键包含分区键。适用于连续整数范围的均匀数据分布——时间序列数据、ID范围分片，基本都是这个套路。

test_partition_172_list_int：LIST分区

按离散值列表划分，分区键是状态字段。p0包含0，p1包含1，p2包含2和3。主键必须包含status。需要注意的是，LIST分区不支持DEFAULT分区，插入不在列表中的值会直接报错。

test_partition_173_range_multi：RANGE分区（非均匀分布）

分区范围呈指数增长——1000、5000、10000、50000、MAXVALUE。这种非均匀策略适合数据分布不均衡的场景，早期范围小后期范围大，同时包含TEXT字段来测试大字段在分区表中的兼容性。

三、唯一键测试：6种唯一约束场景

create_unique_key_table.sql专门验证唯一键约束在迁移时是否出问题。

迁移到PostgreSQL或Greenplum时，有几个注意事项：UNIQUE INDEX对应CREATE UNIQUE INDEX；分区表唯一键必须包含分区键；分布式表要留意数据分布策略；NULL值处理方面，MySQL和PostgreSQL都允许多个NULL，这块倒是相通的。

四、索引全覆盖：5大类索引测试

create_index.sql覆盖了你能想到的大部分索引类型。

基础索引类型包括单列索引、复合索引、前缀索引。复合索引支持最左前缀匹配，前缀索引可以减少索引大小——这些在迁移时都有对应的处理逻辑。

特殊类型索引涵盖全文索引（FULLTEXT，支持自然语言和布尔搜索）、空间索引（SPATIAL，地理空间数据查询）和函数索引（基于表达式创建）。

分区表索引有RANGE、LIST、HASH三种，外加子分区索引。

存储引擎相关索引则区分InnoDB（聚簇索引，支持事务）、MyISAM（非聚簇索引）和MEMORY（内存表索引，数据易失）。

特殊场景索引覆盖了压缩表索引、不同字符集和排序规则的索引、生成列索引等边角情况。

五、42个测试视图：5个复杂度等级

create_view.sql定义了42个测试视图，按复杂度分成五个等级：简单（单表查询，5个）、中等（多表连接，3个）、复杂（子查询和聚合函数，3个）、高级（窗口函数和JSON操作，6个），以及MySQL 8.0特高级视图（20个）。

从简单的view_case01_simple_integers到综合了CTE、JSON_TABLE、正则表达式、GIS空间函数的view_case41_mysql8_ultimate，基本覆盖了视图迁移可能遇到的所有语法场景。

六、110个存储函数：最多涉及10表关联

create_function.sql定义了110个复杂的存储函数。每个函数2到30行代码，覆盖MySQL存储过程的核心语法，有的涉及多达10张表的关联查询。

前100个函数（func_001 ~ func_100）侧重语法转换测试，从分区表、枚举类型、JSON操作到全文检索、空间数据，每个函数都有明确的测试目标。后10个（func_101 ~ func_110）则偏向业务场景，比如复合主外键聚合计算、JSON字段提取、时间类型格式化、高精度数值聚合——这些都是从实际项目中提炼出来的需求。

七、CI流水线：10种数据库版本组合的自动化测试

有测试用例还不够。关键是——每次代码提交，怎么确保不会破坏迁移功能？

MySQL2PG的GitHub Actions CI流水线采用了10种数据库版本组合，按顺序执行，避免资源竞争：MySQL 5.7到8.0，分别对应PostgreSQL的12、14、16、17、18版本。

每个Job的流程都一样：启动MySQL容器，启动PostgreSQL容器，等待两个数据库就绪，然后执行SQL脚本初始化测试数据——167张表、每表10行数据、数百个索引、42个视图、110个函数、用户和权限、分区表注释，全套走一遍。接着生成配置文件，编译运行MySQL2PG，最后上传转换日志。

这套流水线确保每次提交都能验证：167张表结构转换、1670行数据同步、数百个索引转换、42个视图语法、110个函数映射、用户权限、分区表处理、唯一键兼容性——在10种MySQL × PostgreSQL版本组合下一一通过。

八、转换能力全景图

把MySQL2PG的转换能力归纳起来，大致可以分为四个维度。

表结构转换（DDL）：AUTO_INCREMENT变SERIAL或BIGSERIAL，TINYINT(1)变BOOLEAN，INT和INTEGER保持对应，FLOAT变REAL，DOUBLE变DOUBLE PRECISION，DATETIME变TIMESTAMP，VARCHAR不变，TEXT和LONGTEXT统一变TEXT，BLOB和LONGBLOB变BYTEA，JSON保持JSON，ENUM和SET转为VARCHAR(255)，DECIMAL保持，BIT保持，YEAR转INTEGER，UNSIGNED则直接移除改为有符号类型。

视图函数转换（50+函数映射）：IFNULL变COALESCE，IF转CASE WHEN，GROUP_CONCAT变string_agg，CONCAT改用||操作符，NOW变CURRENT_TIMESTAMP，DATE_FORMAT变to_char，STR_TO_DATE变to_date，UNIX_TIMESTAMP变extract(epoch from ...)，JSON函数群对应到jsonb的各种操作——json_build_object、jsonb_set、jsonb_array_length，等等。

索引转换：主键、唯一索引、普通索引一一对应。全文索引转为tsvector配合GIN索引，空间索引依赖PostGIS扩展，前缀索引用表达式索引模拟，函数索引同样转为表达式索引。

分区表处理：RANGE和LIST分区转为PostgreSQL的声明式分区，HASH也对应声明式，KEY分区转为HASH，LINEAR HASH转为普通HASH，子分区转为复合分区，LIST COLUMNS和RANGE COLUMNS分别转化为LIST和RANGE。

九、数据验证：确保一行都不丢

迁移完成后，工具会自动执行数据验证：MySQL行数和PostgreSQL行数逐一对比。只要有一张表的行数对不上，CI流水线就会直接亮红灯，阻止有问题的代码合并。

十、三层测试体系：确保每一次迁移都能成功

有了全面的测试用例，代码本身的稳定性如何保障？MySQL2PG建立了一套三层测试体系。

第一层：单元测试。覆盖核心转换逻辑的每个细节：配置解析、视图函数转换、函数语法映射、数据同步、DDL转换、报告生成、PostgreSQL连接管理。以视图函数转换测试为例，有88个测试用例，验证IFNULL、ROUND、MOD、DATE_FORMAT、JSON函数群的转换是否正确。当前代码覆盖率达到98%。

第二层：集成测试。在真实的MySQL和PostgreSQL环境中，验证端到端迁移流程。84个测试用例覆盖连通性、DDL转换、数据同步、视图转换、索引转换、函数转换、用户权限、运行选项、边界场景和错误处理。每个用例都验证退出码、日志、表结构、数据行数、视图和函数的可用性、索引完整性，以及权限配置。

第三层：CI流水线自动化测试。每次代码提交自动触发，10种数据库版本组合。配备了Race Detector检测并发数据竞争，持续生成覆盖率报告（88%+），有编译检查和静态分析。分支保护机制确保main分支必须有CI通过才能合并，每次发布都经过完整测试流程。

总结下来，这套体系的核心逻辑就四句话：

第一，全覆盖的测试用例——167张表、42个视图、110个函数、4种分区策略、6种唯一键场景、5大类索引，把从基础语法到业务场景的迁移需求全部兜住。

第二，三层测试防护——200+单元测试（98%覆盖率）、84个集成测试、10种CI版本组合，确保代码稳定可靠。

第三，自动化的CI流水线——每次提交自动验证，失败了就不让合并。

第四，严格的数据验证——迁移前后行数对比，数据一致性不放松。

数据库迁移不是赌运气。它靠的是体系化的测试、自动化的流程和严格的代码质量保障。MySQL2PG在这个方向上，提供了一个相当扎实的参考样本。