从RDS迁移到PolarDB需要注意什么？

从 RDS（关系型数据库服务）迁移到 PolarDB，本质上是从传统共享存储架构向云原生存算分离架构的跨越。这不仅仅是换个名字，更是底层机制的重构。

作为过来人，我直接上干货，不谈虚的，只讲迁移过程中最容易踩坑、必须提前准备的几个核心点：

1. 版本与引擎的兼容性是“生死线”

PolarDB 虽然兼容 MySQL/PostgreSQL 协议，但它不是原封不动的复制品。

• 内核版本差异：RDS 和 PolarDB 的内核版本可能不同步。如果 RDS 用了很老的 MySQL 5.6 或 5.7 早期版本，而目标 PolarDB 实例强制要求 8.0+，或者某些特性在旧版中不支持，迁移会直接失败。
  • 对策：先确认源端 RDS 的具体小版本号，再对照 PolarDB 官方支持的版本矩阵。如果版本过低，建议先在 RDS 内部做平滑升级，再迁移。
• 存储过程与函数：这是重灾区。PolarDB 对存储过程、触发器、自定义函数的语法支持度极高，但复杂逻辑（特别是涉及特定系统变量、非标准 SQL 扩展）可能会报错。
  • 对策：使用 DTS（数据传输服务）进行全量 + 增量迁移时，务必开启“结构迁移”并仔细查看报错日志。对于复杂的存储过程，最好人工审查一遍，必要时改写为更标准的 SQL 逻辑。

2. 性能参数的“水土不服”

RDS 和 PolarDB 的默认参数配置逻辑完全不同。

• Buffer Pool 与内存管理：RDS 通常依赖操作系统层面的缓存和固定的 Buffer Pool 设置；PolarDB 则是存算分离，计算节点有独立的内存池，且对 innodb_buffer_pool_size 等参数的敏感度不同。
  • 风险：照搬 RDS 的参数表迁移过去，可能导致查询变慢甚至 OOM（内存溢出）。
  • 对策：不要直接导入 RDS 的 my.cnf。迁移后，基于 PolarDB 的特性重新调整参数，特别是 max_connections（PolarDB 连接数上限通常更高）、sort_buffer_size 以及针对分布式事务的优化参数。
• 主键与索引策略：PolarDB 对聚簇索引的处理机制与传统 InnoDB 略有差异。如果你的业务大量依赖自增 ID 做主键，通常没问题；但如果使用了复合主键或非唯一索引覆盖场景，需要验证执行计划是否发生退化。

3. 数据一致性与时延控制

• 增量同步延迟：在双写切换期间，DTS 负责将 RDS 的变化实时同步到 PolarDB。在高并发写入场景下，网络抖动或解析 Binlog 的压力可能导致极短的延迟。
  • 对策：割接窗口期，必须在应用层加锁或进入维护模式，确保在最后一次同步完成后，没有新的脏数据产生。
• 字符集与排序规则：很多老项目 RDS 用的是 latin1 或特殊的 utf8mb4 配置。PolarDB 默认严格遵循 UTF-8 规范。
  • 风险：特殊符号（如 Emoji、生僻字）或大小写敏感规则不一致，会导致校验失败或数据乱码。
  • 对策：迁移前务必在测试环境跑一次全量比对，重点检查特殊字符和排序结果。

4. 架构变更带来的代码适配

这是最容易被忽视的一点。

• 读写分离路由：RDS 的只读实例通常通过 DNS 或中间件接入。PolarDB 提供了更强大的弹性伸缩和自动读写分离能力，但其 Endpoint 机制可能变化。
  • 注意：如果你的代码里硬编码了 RDS 的 IP 地址，必须改为 PolarDB 的集群地址。同时，检查是否有针对 RDS 只读实例的特殊超时设置，PolarDB 的响应时间模型不同，可能需要调整应用端的 SocketTimeout。
• 临时表与会话级变量：PolarDB 对临时表的清理机制和会话变量的生命周期管理更严格。某些在 RDS 上能跑通的“黑魔法”SQL（比如利用会话变量绕过某些限制），在 PolarDB 上可能会失效。

5. 割接实操的“小心眼”

• 回滚方案：千万别以为迁移成功就万事大吉。一定要准备好一键回滚脚本。如果割接后发现 PolarDB 性能异常或数据有误，必须能在分钟级内切回 RDS。
• 监控预热：在正式割接前，把 PolarDB 的监控项（CPU、IOPS、连接数、慢查询）调优好。不要等到上线那天才发现预警阈值设得太低，导致误报频发。
• 应用重启：大多数情况下，数据库切换不需要停机应用，但为了保险起见，建议在低峰期进行短暂的应用重启，以清除旧的数据库连接池，建立新的长连接。

总结

从 RDS 迁到 PolarDB，技术难点不在“搬运”，而在“适配”。

1. 先测后动：拿生产数据的脱敏副本，在测试环境完整演练一遍全流程。
2. 参数重构：忘掉 RDS 的默认配置，按 PolarDB 的最佳实践重新调优。
3. 代码审查：重点排查存储过程、特殊字符处理和连接方式。

只要把这三点吃透，这次迁移就是平滑升级，而不是灾难现场。