PostgreSQL 和 MySQL 都是主流开源关系型数据库，很多人会想当然地认为"反正都是 SQL，改改连接串就行"。但实际上两者在类型系统的严谨程度、SQL 语法风格、并发控制机制、扩展生态上差异极大，PostgreSQL 又是一个功能极其"激进"的数据库（JSONB、数组类型、丰富的约束和扩展），迁移到相对"务实克制"的 MySQL，往往意味着不少功能需要重新设计而不是简单转换。本文按迁移实际流程梳理关键注意事项。

一、迁移前评估

1. 先摸清 PostgreSQL 特有能力的使用程度

迁移成本高不高，很大程度取决于业务用了多少 PostgreSQL 的"特色功能"。建议先扫描以下几类对象的使用情况：

• 是否大量使用 JSONB 字段做半结构化存储；
• 是否用了数组类型（ INTEGER[]、 TEXT[]）；
• 是否用了 ENUM 类型、自定义组合类型（ CREATE TYPE）；
• 是否依赖扩展（ PostGIS 地理信息、 pg_trgm 模糊搜索、 hstore 等）；
• 是否用了继承表、表分区、物化视图、外部表（ FDW）；
• 是否用了 PL/pgSQL 写了复杂存储过程/触发器。

这些功能里，有些 MySQL 有近似替代（如 JSON 类型），有些完全没有对应物（如 PostGIS、 FDW、继承表），后者需要单独评估重构方案，往往是迁移里工作量最大的部分。

2. 明确迁移路径：停机迁移 or 在线迁移

• 停机迁移：适合数据量可控、能接受维护窗口的场景，用 pg_dump 导出+转换+导入即可，流程简单。
• 在线迁移：核心业务系统建议采用"全量+增量 CDC 同步+切换"的方式，常见工具有 AWS DMS、pg_chameleon 等，减少停机时间，但技术复杂度和验证成本更高。

二、数据类型映射与语义差异

这是从 PostgreSQL 迁移到 MySQL 时最容易"表面迁完、实际语义变了"的环节。

三、SQL 语法与行为差异

• 标识符大小写：这是最容易踩的坑之一。PostgreSQL 中不加引号的标识符默认会被转成小写，MySQL 在 Linux 下默认区分大小写（表名尤其明显，受 lower_case_table_names 参数影响），迁移脚本里如果混用了大小写命名，行为可能不一致，建议统一规范后再迁移。
• RETURNING 子句：PostgreSQL 的 INSERT/UPDATE/DELETE ... RETURNING 非常常用，MySQL 不支持该语法，需要改写为"先执行语句，再用 LAST_INSERT_ID() 或额外 SELECT 查询"的方式获取结果，涉及应用层代码改动。
• UPSERT 语法：PostgreSQL 的 INSERT ... ON CONFLICT DO UPDATE 需要改写为 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE，两者在冲突判定列的指定方式、语义细节上不完全等价，需要逐条核对。
• 窗口函数与 CTE：两边对标准窗口函数和 WITH CTE 的支持都不错（MySQL 8.0+），但递归 CTE 写法、 LATERAL 关联子查询等高级特性的支持程度和语法细节仍有差异，需要在低版本 MySQL（5.7 及以下）上特别小心——很多语法根本不支持。
• 字符串拼接：PostgreSQL 用 ||，MySQL 默认用 CONCAT() 函数（ || 在 MySQL 里默认表示逻辑或，除非开启 PIPES_AS_CONCAT sql_mode），这是极易被忽略的语法差异，批量替换时要用工具辅助而非人工逐个改。
• LIMIT/OFFSET：两者语法接近，但 PostgreSQL 支持 FETCH FIRST n ROWS ONLY 标准 SQL 写法，迁移时统一改成 MySQL 的 LIMIT 写法即可，风险较低。

四、存储过程、触发器与扩展能力

• PL/pgSQL → MySQL 存储过程：PL/pgSQL 语言能力（丰富的控制流、异常处理、动态 SQL、复合类型返回）比 MySQL 存储过程强大得多。复杂的业务逻辑建议评估是否迁移到应用层实现，而不是逐句"翻译"，翻译成本高且容易引入隐藏 bug。
• 触发器差异：PostgreSQL 触发器可以绑定到语句级/行级、 BEFORE/AFTER/INSTEAD OF，还支持通过函数灵活复用逻辑；MySQL 的触发器功能相对简化，不支持 INSTEAD OF，也没有 PostgreSQL 那种"触发器函数"复用机制，复杂触发器链路需要重新梳理设计。
• 扩展能力（Extension）：如果业务用到了 PostGIS（地理空间）、 pg_trgm（模糊匹配）、 hstore（键值存储）等扩展，MySQL 没有直接对应物，需要单独选型替代方案（比如地理位置数据改用 MySQL 8.0 的空间数据类型，模糊搜索改用全文索引或引入 Elasticsearch 等外部系统），这部分往往是迁移项目里最耗时的技术攻关点。
• 分区与继承表：PostgreSQL 的表继承、声明式分区与 MySQL 分区表的实现机制、限制条件都不同（MySQL 分区键必须包含在主键/唯一键中等限制），需要重新设计分区方案，不能照搬原表结构。

五、事务与并发模型差异

• 两者默认隔离级别不同：PostgreSQL 默认 READ COMMITTED，MySQL（InnoDB）默认 REPEATABLE READ，隔离级别差异会直接影响并发场景下的锁等待和幻读表现，依赖具体隔离级别语义的业务逻辑需要重新验证。
• PostgreSQL 的 MVCC 实现（多版本存储+ VACUUM 回收）与 MySQL InnoDB 的 MVCC（基于 undo log）机制不同，长事务、大批量更新场景下的资源占用和性能表现不能直接类比，建议做专门的压测。
• 死锁检测、锁粒度、加锁策略的细节差异，也建议针对高并发写入场景做专项测试，而非假设迁移后行为一致。

六、迁移工具选型

选型建议优先考虑：是否需要在线增量同步、JSONB/数组等复杂类型的转换规则、团队对工具本身的运维能力。

七、迁移后校验清单

1. 数据完整性校验：不能只对比总行数，建议按主键分块做校验和比对，尤其关注 JSON、数组类型拆分/转换后的数据是否完整无损。
2. 业务语义回归：重点验证标识符大小写、UPSERT 逻辑、时区处理、布尔值这几类"看似迁移成功、实际语义已变"的高风险点，用真实业务场景跑一遍。
3. 性能基准对比：PostgreSQL 和 MySQL 的查询优化器、索引类型（如 PostgreSQL 的 GIN/GiST 索引在 MySQL 中没有直接对应）差异很大，原本依赖特殊索引类型的高频查询上线前必须重新做执行计划分析和索引设计。
4. 保留回滚能力：正式切换后仍建议保留一段时间的双写或快速回滚方案，观察真实流量下是否暴露测试阶段未覆盖的边界场景。

小结

PostgreSQL 迁移到 MySQL，本质上是从一个"类型系统严谨、功能丰富"的数据库迁移到一个"生态成熟、相对简化"的数据库，最大的挑战不在于语法翻译，而在于 JSONB、数组、扩展、继承表等 PostgreSQL 特色能力在 MySQL 里往往没有直接对应物，需要结合业务场景重新设计。建议把迁移拆解为"特性摸底—类型/结构重新设计—语法转换—双轨校验—灰度切换"五个阶段，尤其重视迁移前的特性摸底工作，这决定了后续工作量的量级。