一个 Go 服务的主数据库从 MySQL 迁到 PostgreSQL。

真正让我开始紧张的，不是第一条 SQL 报错，而是代码里到处传的那个全局变量：MysqlDb。

业务代码拿到的本来应该是“主业务库连接”，但这个名字已经把实现写死了。只要它继续叫 MysqlDb，后面所有人都会默认这套代码还是围着 MySQL 转。于是第一步我先把它改成了更中性的 WebcenterDb。

这个重命名当然不会自动解决兼容问题，但它至少划清了一条边界：业务层不应该关心底层到底是 MySQL 还是 PostgreSQL。

迁移时我主要从几类地方往下扫。

连接层最容易改，但也最容易漏。驱动要换，DSN 要换，连接参数要重新确认，健康检查和初始化顺序也要跟着看一遍。

模型层更麻烦。MySQL 和 PostgreSQL 在自增、布尔值、时间、JSON、数组、默认值上都有差异。GORM 能帮忙生成 SQL，但它不能替你判断字段语义有没有变。

查询层风险最大，尤其是散落在各处的原生 SQL。

MySQL 专用函数、时间格式化、字符串拼接、模糊查询、大小写行为、分页排序、字段名大小写，这些平时不显眼的东西，换库时都会冒出来。还有一些查询在 MySQL 里能跑，不代表它在 PostgreSQL 里语义一样。

AI 在这种迁移里是有用的。

它适合帮忙扫 MysqlDb、MySQL 专用函数、可疑原生 SQL，也适合根据已有查询补测试样例。但它不知道某个奇怪 SQL 是历史 Bug，还是客户已经依赖了三年的“业务规则”。迁移里最难的部分不是改语法，而是判断哪些行为必须保留，哪些行为可以趁这次修掉。

数据库迁移是一场很诚实的架构检查。

平时以为已经被 ORM 隔离掉的数据库细节，会在换库时重新出现。变量命名、模型定义、原生 SQL、测试环境、回滚方案，都会把系统真实的边界暴露出来。