GaussDB 迁移别只盯语法：三个常被低估的改造点

把业务从自建数据库迁到云上数据库，很多团队的评估表上只有两行：SQL 语法兼容度、迁移窗口多长。真正让项目拖长的，往往不是语法，而是那些在评估表上写不出来的改造点。

第一，事务与锁的行为差异。同样的语句在不同引擎里，锁粒度、隔离级别默认值、死锁检测策略都可能不同。上线前应该按真实业务并发压测一批长事务和批量更新，观察锁等待曲线，而不是只在测试库跑几条典型 SQL。

第二，序列、自增与分布式主键。单机自增在分布式环境里会变成瓶颈甚至冲突源，迁移前要把主键生成策略梳理一遍，统一到序列或全局唯一 ID 服务，并检查历史数据是否需要回填。

第三，慢查询的成因会变。原来的执行计划优化手段未必适用，统计信息收集策略、并行度、索引选择都不一样，迁移后要重新建立慢 SQL 基线和告警阈值，否则性能问题往往在业务高峰才暴露。

还有一点常被忽略：备份与恢复策略。迁移后必须验证全量备份和增量备份在目标环境能正常恢复，恢复演练的耗时直接决定了真实故障时的可用性上限。

数据库迁移不是一次数据搬运，而是一次运行时行为的重新标定。把这几件事在割接前做完，比多写几个兼容补丁更有价值。