业务涨到一定规模后，自建数据库往往让人头疼：备份要有人盯，扩容要排期，主从切换出问题时半夜也得爬起来。把数据库交给云厂商托管，是很多技术团队的常见选择。阿里云的数据库产品线比较全，但 RDS、PolarDB、Tair 这些名字看着接近，真去选的时候容易选错。下面用一个电商团队的迁移经历，说说怎么先看清需求，再动手迁移。
先分清阿里云几类数据库
阿里云的数据库更像一组按场景拆开的服务。先看业务的访问方式，再决定用哪一类，通常比一上来就追高配更省钱，也更少返工。
- 云数据库 RDS：兼容 MySQL、PostgreSQL、SQL Server 等主流引擎。大多数在线业务系统用它就够了，运维压力小，也是很多团队迁上云的第一站。
- PolarDB：云原生关系型数据库，存储和计算分离。访问量忽高忽低、又需要快速扩容的业务，可以重点看它。
- Tair（兼容 Redis）：内存型数据库，适合缓存、会话存储、排行榜这类对响应速度敏感的功能。
- AnalyticDB、MongoDB 版等：分别对应分析型负载和文档型数据。数据模型和查询方式不同，要单独评估，不能套用前面的判断。
实际判断可以简单些。订单、库存、账户这类交易数据要求强一致，优先放在关系型产品里。热点数据和缓存放到内存型产品中。报表和分析查询尽量从线上库里拆出去，否则一条大查询就可能拖慢下单。
一家中小电商的迁移过程
有个做日用品线上销售的团队，日订单从几百单涨到几万单。数据库还放在自有机房，两名运维既管服务器，也管数据库。问题一个个冒出来：大促时主库负载顶到很高，从库延迟明显；备份脚本偶尔失败，却没人及时发现；有一次误删数据，恢复用了大半天。
他们的目标很朴素：系统更稳，运维少操心，迁移时业务别停。整个过程大致分四步。
第一步是摸清现状。团队梳理了核心库的表结构、数据量、每天的增长量，以及高峰时段的读写比例。读请求占了八成以上，订单和商品是主要的读写表，用户行为日志量最大，但对实时性要求不高。这个结论直接决定了后面的架构怎么搭。
第二步是选型。主库用 RDS for MySQL，采用一主多从，把商品浏览这类查询分到只读实例上。日志数据迁到单独的分析型存储，不再占用线上库的资源。原来自己维护的 Redis 缓存换成兼容 Redis 的 Tair，省下了一部分维护工作。
第三步是迁移，也是最容易出岔子的一步。团队先用数据同步工具做全量，再做增量，并在测试环境完整演练了两次，每一步的耗时都记下来。正式切换放在凌晨流量最低的时段。应用里的数据库连接地址提前做成可配置项，切换时只改配置、滚动重启即可。切换前后核对了核心表的行数和几个关键业务指标，确认一致之后，才关掉旧库的写入。
第四步是把保障机制立起来。开启自动备份和日志备份，支持按时间点恢复；主库配置监控告警，覆盖连接数、慢查询和主从延迟；每个季度做一次恢复演练。备份任务显示成功不够，能不能恢复，要靠演练来验证。
迁移半年后，哪些地方变了
半年后回头看，变化比较具体。大促期间主库压力明显下降，读流量分流以后，页面响应时间也比之前稳定。误操作可以恢复到某个时间点，不再需要整库回滚。运维人员从日常的机器维护里抽出身来，有时间去优化 SQL 和表结构。
迁移过程中也有几处需要提前想清楚：
- 迁移前一定要做完整演练。光在纸上写切换流程，遇到真实的连接和权限问题时还是会措手不及。
- 读写分离会带来主从延迟。刚写入就要立刻读取的逻辑，比如下单后马上查订单详情，要在代码里做兼容，例如这类读取直接走主库。
- 费用不只看实例规格。存储、备份、流量和只读实例的数量都会计入账单，建议每月看一次账单，只读实例按真实负载增减。
- 权限和网络要按最小化原则配置。数据库不要直接暴露在公网，访问白名单定期清理，用不到的账号及时停用。
回到选型本身
阿里云数据库主要解决的是基础设施层面的问题：稳定性、扩展性和运维效率。表结构合不合理、SQL 写得好不好，还得团队自己把关。选型时先看数据特征和访问方式，再决定用哪类产品；迁移时靠充分演练控制风险。这样，云上的数据库才能发挥作用。
