PolarDB 实践：千里达票务系统订单库从 RDS 到云原生数据库的升级
RDS MySQL 读写分离跑了一年多，订单库到了瓶颈：读写分离实例加一台只读节点成本翻倍，跨节点一致性延迟偶尔秒级，对账数据对不上。阿里云 PolarDB 云原生数据库一份存储最多 15 个只读节点，主从延迟毫秒级，单节点性能比同规格 RDS 高 3 倍。我们把订单主库迁到了 PolarDB。
一、为什么升级 PolarDB
- 存储计算分离：扩容不用买整台机器，只加计算节点；
- 主从延迟毫秒级：对账、报表读从库不再有"差几秒"的问题；
- 兼容 MySQL：业务代码几乎不用改。
二、迁移路径
老 RDS MySQL → DTS 全量+增量 → 新 PolarDB MySQL
观察 1 周 → 切流量 → 老库保留 1 个月
三、关键收益
3.1 只读节点弹性
- 平时 1 主 2 只读；
- 节前一键扩到 1 主 8 只读；
- 节后缩回来，按小时计费。
3.2 列存索引
订单分析（按景区/按月汇总）直接在 PolarDB 列存索引上跑，不用另买数仓，秒级出报表。
3.3 闪回查询
误删了一批订单，直接查 1 小时前的数据状态，不用从备份恢复。
四、踩坑复盘
- SQL 兼容性：个别老 SQL 用了 MySQL 5.6 的写法，PolarDB 8.0 报错。解决：上线前用 DTS 兼容性检查跑一遍；
- 连接数配置：PolarDB 默认连接数上限按规格算，节假日连接打满。解决：连接池改 PgBouncer，业务侧短连接改长连接；
- 备份策略：早期只开了自动备份，误删 2 天的数据找不回。解决：开 PITR 时间点恢复，保留 30 天；
- 监控没配：PolarDB 的指标和 RDS 不完全一样，早期告警规则漏配。解决：重新按 PolarDB 指标体系配告警。
五、效果与总结
迁到 PolarDB 后，订单库 P99 延迟降了 40%，只读节点扩容从"买机器等半天"变成"控制台点一下"。对千里达票务系统这种持续增长的核心交易库，云原生数据库是中长期方向。
