引子
某客户的核心业务系统跑在 MySQL 上 5 年了，因合规要求需要迁到 PostgreSQL，且业务不能 停超过 2 小时。这次迁移是浩途近年最复杂的一次基础设施变更，复盘写下来。
整体策略：双写 + 灰度切流
- 先在生产环境双写（MySQL 主、PostgreSQL 影子）
- 影子库跑业务回归 + 数据校对
- 只读流量先切到 PostgreSQL 灰度
- 写流量按业务模块逐步切换
- MySQL 降级为只读 backup，30 天后下线
踩过的坑（占位）
- 字符集 / 时区差异
- 自增 ID 的连续性
- 全文索引语义差异
- 触发器与存储过程的等价改写
- 应用层 ORM 的 SQL 兼容
（每个坑的具体方案与回归脚本后续展开）
写在最后
数据库迁移没有"标准方案"，只有"对你的业务最小风险的路径"。预演 2-3 次比文档读 10 份更有用——这是浩途技术团队的硬经验。