第一次把业务搬上云，很多团队会在阿里云数据库的产品列表前停下来。RDS、PolarDB、Tair、AnalyticDB 名字很像，擅长的事情却不同。选错了，后面迁移的代价不小。这篇文章先说各产品适合什么，再列出选型时要问的几个问题，最后用一次迁移过程做例子。
四款产品各管什么
- 云数据库RDS：托管的关系型数据库，支持MySQL、PostgreSQL、SQL Server和MariaDB。备份、主备切换和补丁升级由平台处理。后台管理、订单、会员这类常规业务系统，先看RDS通常就够了。
- PolarDB：存储与计算分离。计算节点能较快地增减，多个只读节点读的是同一份数据。读多写少、流量波动大、需要临时扩容的业务更适合它。
- Tair（兼容Redis）：内存型的缓存与存储服务，适合热点商品、登录会话、排行榜这类要求低延迟的读写。它一般搭配主库使用，不能代替主库存放交易数据。
- AnalyticDB：面向大数据量的分析型数据库，适合报表、实时看板和多维度统计。交易数据不要直接写进去。
选型前先回答四个问题
- 数据是交易型还是分析型？订单、库存这类要求强一致的写入，放在RDS或PolarDB上。月报和用户行为分析，交给AnalyticDB更省心。两类查询混在同一个库里，分析任务跑起来会拖慢交易。
- 应用用的是什么数据库引擎？代码基于MySQL，迁到RDS MySQL或PolarDB MySQL，改动通常不大。如果要换引擎，就得逐个检查存储过程、函数和语法差异，这部分工作量常被低估。
- 峰值压力有多大，持续多久？大促时一两个小时的高峰，和全天都稳定在高位的负载，对扩容方式的要求完全不同。先拿监控数据看一个月的曲线，比凭印象估计可靠。
- 团队有没有人负责数据库？托管服务能省掉大部分日常维护，但参数调优和慢SQL治理还得有人管。没有这个人，买了托管也容易出问题。
案例：一家服装电商的迁移过程
下面是一个虚构但很典型的场景，用来说明决策怎么走。某服装电商原来把订单、商品和会员数据都放在自建MySQL服务器上。每逢促销，商品详情页的查询量会涨到平时的几十倍，数据库CPU长时间打满，用户投诉集中在活动开始的第一个小时。
团队没有急着换产品，先拆分负载。商品和会员查询迁到RDS MySQL，并开启只读实例分担读请求，订单写入仍走主库。商品详情的热点数据放进Tair。缓存命中率稳定后，数据库的读压力明显下降。
一年后业务继续扩大，只读实例的同步延迟开始影响库存展示，库存数字有时对不上。团队评估后，把核心库迁到PolarDB MySQL。存储与计算分离之后，大促前临时加几个只读节点，活动结束再缩回去，全程没有停机。
迁移时，团队用数据传输服务DTS做全量加增量同步。切换前后各保留一段时间的双写校验，确认订单和库存数据一致后才正式切流。切换窗口控制在几分钟以内。
迁移前要做的几件事
- 用真实流量回放慢SQL。在测试环境跑一遍，对比新旧库的执行计划。如果优化器选的索引变了，要在切流前发现。
- 核对字符集、时区和自增主键。这几处最容易出现静默的数据错误。时区配置不一致时，时间字段可能偏移几个小时，应用不报错，数据却已经错了。
- 写好回滚方案，并实际演练一次。只停留在文档里的回滚步骤，到了切流出问题的时候往往用不上。
- 提前设置监控告警。重点盯连接数、主从延迟和慢查询数量。阈值可以先按平时的基线设，迁移后再根据实际表现调整。
成本怎么估
云数据库的费用通常由实例规格、存储容量、备份空间和流量组成。具体价格以阿里云官网的计费页面为准，本文不给具体数字。估算可以分三步：先算日常负载需要的规格，再算大促峰值需要的规格，最后算只读节点实际运行的时长。如果产品支持按量付费，大促期间临时扩容的花费，有时比全年长期持有高配实例要低。是否划算，要用自己业务的监控数据来算。
怎么选更稳
阿里云数据库把大量重复的运维工作交给平台，团队可以把精力放在业务和数据模型上。选型时先看数据类型、引擎兼容性和峰值特征，再决定要不要升级产品。分阶段迁移，一般比一次性重构稳妥。
