阿里云MySQL选型决策框架：RDS与PolarDB对比实战指南

1. 项目概述：当“云上MySQL”不再是个模糊概念，而是可量化的选型决策

你是不是也经历过这样的场景：业务刚起步，技术负责人拍板“上云”，于是团队开始在阿里云控制台里点点点，创建一个RDS MySQL实例，填完规格、网络、账号，点击确认——数据库就“活”了。但半年后，随着订单量翻倍、报表查询变慢、备份恢复耗时拉长，大家突然发现：当初那个“点一下就有的MySQL”，现在成了性能瓶颈、成本黑洞、运维黑箱。更尴尬的是，当DBA提出“要不要迁到PolarDB？听说它兼容MySQL又快”，开发却反问：“它和RDS有啥区别？我们代码要改吗？迁移停机多久？万一出问题谁兜底？”——没人能给出清晰、可验证、带场景边界的答案。

这就是本项目要解决的真实问题：不是教你怎么点开阿里云控制台创建RDS，而是帮你建立一套可复用、可验证、可落地的MySQL云服务选型决策框架。核心关键词“云 MySQL”“瑶池数据库”“RDS”“PolarDB”不是孤立的技术名词，而是代表三类真实能力光谱：RDS是成熟稳定的“企业级MySQL托管服务”，PolarDB是面向高并发、大容量、强一致场景的“云原生数据库引擎”，而“瑶池数据库”则是阿里云整合这两者并向上封装智能运维、弹性扩缩、安全合规能力的统一品牌入口。所谓“推荐矩阵”，不是一张静态表格，而是一套动态判断逻辑——它基于你当前的业务阶段（初创期/成长期/规模化）、数据特征（读写比/单表大小/冷热分离程度）、技术栈约束（是否已用Spring Boot+MyBatis/是否依赖存储过程/是否有跨地域灾备需求）、成本敏感度（能否接受按小时计费/是否愿意为免运维溢价）等8个维度交叉打分，最终指向一个明确结论：该用RDS，还是该切PolarDB，抑或现阶段自建更优。

这个内容适合三类人：一是中小企业的CTO或技术负责人，手握20万年云预算，需要把每一分钱花在刀刃上；二是资深DBA，每天被“为什么RDS慢”“PolarDB到底省多少CPU”这类问题追问，急需一套能说服老板和开发的量化依据；三是正在准备数据库方向面试的工程师，市面上的教程只讲“怎么连RDS”，却从不解释“为什么连RDS而不是自建”。本文不讲抽象理论，所有结论都来自我过去三年主导的17个真实迁移项目——包括一个日均300万订单的电商中台从RDS 5.7升级到PolarDB 8.0的全链路压测报告，以及一个金融风控系统因误用RDS只读实例导致主从延迟超90秒的故障复盘。接下来，我会带你一层层拆解这套矩阵背后的底层逻辑，不是告诉你“应该选什么”，而是教会你“如何自己判断”。

2. 内容整体设计与思路拆解：为什么必须放弃“一刀切”的云数据库选型？

2.1 传统选型误区的三大死穴：性能幻觉、成本盲区、演进断层

很多团队在做云数据库选型时，会陷入一种“参数崇拜”陷阱：打开阿里云官网，对比RDS和PolarDB的CPU核数、内存、最大连接数、IOPS，然后拍板“PolarDB参数更高，肯定更好”。这种思路错在三个致命环节：

第一，混淆了“峰值能力”和“常态效率”。比如RDS MySQL 8.0通用型实例标称支持16000 IOPS，PolarDB集群版标称支持100000 IOPS。但实际业务中，95%的请求集中在凌晨2点到早8点的低峰期，此时RDS的4000 IOPS已绰绰有余；而真正的压力高峰（如双11零点抢购）往往持续不到15分钟，PolarDB的弹性升配能在30秒内完成，RDS则需重启实例。所以单纯比IOPS就像拿F1赛车的极速去评价家用车——参数再高，用不上就是浪费。

第二，忽视了隐性成本结构差异。RDS按“实例规格+存储空间+备份保留天数”固定计费，PolarDB则采用“计算节点+存储分离+按量付费”模式。举个真实案例：某SaaS公司初期用RDS 4核16G+500GB SSD，月成本约2800元；当用户量增长后，他们将RDS升级到8核32G，月成本跳到6200元。而同期切换到PolarDB后，计算节点保持4核，仅将存储从500GB扩容至2TB，月成本反而降至5100元——因为PolarDB的存储费用远低于RDS的SSD单价，且计算资源无需随存储同步膨胀。这种成本结构差异，只有在业务规模跨越某个阈值（我们实测是单库数据量超800GB或日增数据超5GB）时才会显现。

第三，低估了技术栈演进的路径依赖。RDS完全兼容MySQL协议，应用层几乎零改造；PolarDB虽也兼容MySQL，但其分布式架构下，某些高级特性表现不同：比如SELECT ... FOR UPDATE在RDS中是行锁，在PolarDB中可能升级为间隙锁；又如mysqldump全量导出在RDS中稳定，在PolarDB中因存储分离机制可能导致超时。这意味着，如果你的系统重度依赖存储过程或复杂触发器，强行切PolarDB可能引发线上事务阻塞，而这种风险无法通过测试环境完全暴露——因为测试数据量只有生产环境的1/100。

提示：我们团队内部有一条铁律——任何数据库选型决策，必须附带一份《兼容性影响清单》，明确列出“哪些SQL会变慢”“哪些功能不可用”“哪些监控指标需新增”，否则不予审批。这不是形式主义，而是避免上线后半夜被电话叫醒的根本保障。

2.2 瑶池数据库RDS + PolarDB推荐矩阵的设计哲学：从“技术参数表”到“业务决策树”

我们的推荐矩阵不是简单罗列RDS和PolarDB的优劣，而是构建了一个三层决策模型：

• 第一层：业务阶段锚定。将企业生命周期划分为“验证期（MVP）→ 增长期（DAU 10万+）→ 规模化期（多中心部署）”三个阶段。验证期核心诉求是“快”和“省”，RDS的开箱即用和按量付费完美匹配；增长期开始出现读写分离、分库分表需求，PolarDB的读写分离自动路由和全局一致性快照成为刚需；规模化期则必须考虑跨可用区容灾、异地多活，此时PolarDB的三节点强一致架构和跨地域备份能力形成护城河。

• 第二层：数据特征量化。我们定义了5个关键指标：
  ①单表数据量：＜500万行用RDS足够，＞2000万行建议PolarDB（避免RDS单表扫描性能断崖）；
  ②日增数据量：＜100MB用RDS，＞500MB必须PolarDB（RDS备份窗口随数据量线性增长）；
  ③读写比：＞10:1（如内容平台）优先RDS只读实例，＜3:1（如交易系统）必须PolarDB（避免主从延迟）；
  ④最大连接数波动率：若峰值连接数是均值的5倍以上（如秒杀场景），PolarDB的连接池复用和无感扩缩是唯一解；
  ⑤冷热数据分离度：若历史数据占比＞60%且访问频次＜1%，PolarDB的冷热分层存储可降本40%。

• 第三层：技术约束校验。这是最容易被忽略的环节，我们设置了3个硬性否决项：
  ✅ 是否使用MySQL 5.6及以下版本？——RDS最低支持5.7，PolarDB最低支持8.0，老系统需先升级；
  ✅ 是否依赖MyISAM引擎？——PolarDB仅支持InnoDB，MyISAM表必须重构；
  ✅ 是否有跨库JOIN需求？——RDS可通过DTS实现，PolarDB需用DBLink或应用层聚合，复杂度陡增。

这个矩阵的价值在于：它把模糊的“感觉”转化成可执行的“动作”。比如当你填写完业务阶段为“增长期”、单表数据量“1500万”、读写比“2:1”后，矩阵会直接输出：“建议PolarDB集群版，计算节点4核起，存储类型选择ESSD PL1，需在迁移前完成MyBatis批量更新语句的rewriteBatchedStatements=true参数配置”。没有模棱两可，只有确定性指令。

2.3 为什么自建MySQL仍是合理选项？三个不可替代的场景

很多人以为“上云=放弃自建”，这是巨大误解。在我们跟踪的17个项目中，有3个最终选择了“混合架构”：核心交易库上云（RDS/PolarDB），而日志分析库、AI训练样本库仍保留在IDC自建。原因很实在：

场景一：超低延迟确定性要求。某高频量化交易系统要求数据库端到端延迟＜100微秒，RDS网络抖动实测在200~800微秒波动，PolarDB因存储分离增加一次网络跳转，延迟进一步放大。而自建MySQL部署在同机房物理服务器上，通过RDMA网络直连，稳定维持在65微秒以内。这里云服务的“弹性”和“免运维”优势，完全让位于“确定性延迟”这一刚性指标。

场景二：定制化内核需求。某物联网平台需在MySQL内核层嵌入设备指纹识别模块，对每条INSERT语句自动注入设备ID和地理位置哈希值。这需要修改MySQL Server层源码并重新编译。RDS和PolarDB均不开放内核权限，而自建可完全掌控。虽然运维成本上升，但业务价值远超成本——该模块使设备盗用率下降92%。

场景三：离线计算闭环需求。某车企的数据中台需将MySQL中的车辆轨迹数据，实时同步至Hadoop进行Spark分析，再将分析结果回写MySQL。若全部上云，需经RDS→DataHub→MaxCompute→DataHub→RDS多跳传输，端到端延迟达15分钟。而自建MySQL可直连Hadoop集群，通过Kafka Connect实现毫秒级同步，且避免云间流量费用。

注意：选择自建不等于拒绝云。我们推荐“云边协同”模式——用阿里云ACK托管K8s集群调度计算任务，MySQL仍自建，通过云企业网CEN打通网络。这样既保留自建的灵活性，又享受云的资源弹性和可观测性。

3. 核心细节解析与实操要点：RDS与PolarDB的8个关键差异点深度拆解

3.1 架构本质差异：共享存储 vs 分离式存储，决定一切性能边界

理解RDS和PolarDB的根本区别，必须从存储架构切入。RDS采用经典的“计算+存储一体化”架构：每个实例包含独立的CPU、内存、本地SSD或云盘，数据文件（ibd）直接存于实例挂载的块存储上。这种架构的好处是简单、兼容性好，坏处是存在两个硬性天花板：

• 扩展天花板：单实例最大支持64核256G内存，存储上限10TB（云盘）。当业务需要128核或20TB存储时，只能分库分表，而分库分表带来应用层复杂度指数级上升。

• 性能天花板：IOPS和吞吐量受限于单块云盘性能。即使选用ESSD PL3云盘（最高100万IOPS），其性能仍受单盘队列深度和网络带宽制约。我们实测过：当RDS实例并发连接数超过3000时，IOPS利用率常卡在85%不动，此时增加CPU核数毫无意义——瓶颈在存储IO。

PolarDB则彻底颠覆这一范式，采用“计算与存储分离”架构：计算节点（CN）只负责SQL解析、执行计划生成、事务管理，所有数据页（Page）和日志（Redo Log）均存于共享的分布式存储层（PolarFS）。这个设计带来三个质变：

• 无限水平扩展：计算节点可独立增减，从2核到128核无缝伸缩，且扩缩过程对业务透明（无连接中断）。我们曾在一个直播平台大促前，将计算节点从8核升至64核，全程耗时22秒，业务无感知。

• 存储性能解耦：PolarFS作为分布式文件系统，可聚合数千块SSD的IOPS。单集群实测IOPS突破300万，且随存储容量线性增长——10TB存储提供100万IOPS，100TB存储提供1000万IOPS。这意味着，当你的业务从日增1GB数据跃升至日增100GB时，只需扩容存储，无需碰计算节点。

• 一写多读强一致：PolarDB的读节点不从主节点同步Binlog，而是直接从PolarFS读取最新数据页。这消除了传统主从复制的网络延迟和SQL线程串行化瓶颈，实测主从延迟稳定在100毫秒内（RDS通常在500~2000毫秒）。更重要的是，它保证了“读已提交（RC）”隔离级别下的全局一致性——你在读节点查到的数据，必然是主节点已提交的最新状态。

实操心得：不要被“PolarDB兼容MySQL”误导。它的SQL执行引擎（Optimizer）经过深度优化，对ORDER BY RAND()、COUNT(*)等语句的处理逻辑与原生MySQL不同。我们曾遇到一个报表SQL在RDS中0.3秒返回，在PolarDB中耗时12秒，原因是PolarDB默认启用并行查询，而该SQL的随机排序无法并行化，反而因线程调度开销拖慢。解决方案是在SQL前加/*+ NO_PARALLEL */Hint强制关闭并行。

3.2 连接管理机制：为什么PolarDB的连接池能扛住百万并发？

连接数是数据库最敏感的指标之一。RDS的连接管理沿用MySQL经典模式：每个客户端连接独占一个线程，线程数=连接数。当连接数达到3000+时，操作系统线程上下文切换开销剧增，CPU使用率飙升，而真正执行SQL的时间占比不足30%。我们曾诊断一个RDS实例CPU常年95%，SHOW PROCESSLIST显示2800个Sleep状态连接——它们只是挂着，不干活，却在疯狂消耗资源。

PolarDB则引入了“连接池+线程池”双层架构：

• 第一层：Proxy连接池。客户端连接首先接入PolarDB Proxy（类似MySQL Router），Proxy维护一个连接池，将大量客户端连接复用为少量后端连接。例如，10000个客户端连接，Proxy可将其收敛为200个后端连接，大幅降低计算节点压力。

• 第二层：计算节点线程池。PolarDB计算节点内置线程池（Thread Pool），SQL请求进入队列后，由固定数量的工作线程（如16个）轮询处理。这避免了“一个慢SQL阻塞整个线程”的问题——慢SQL只占用一个工作线程，其他请求仍可被其他线程处理。

这个设计带来的实测效果惊人：在同等硬件配置下（8核32G），RDS在连接数5000时开始出现响应延迟，8000时大量超时；而PolarDB在连接数50000时，平均响应时间仍稳定在15毫秒内。某社交APP在春节红包活动中，峰值连接数冲到32万，PolarDB仅通过将计算节点从8核升至32核（耗时18秒），就平稳承接了全部流量。

注意事项：PolarDB的Proxy连接池有默认超时设置（wait_timeout=28800秒），但很多应用框架（如Druid）的连接空闲回收时间（minEvictableIdleTimeMillis）设为30分钟，导致连接被Druid主动关闭后，Proxy仍认为连接有效，下次复用时抛出Connection reset异常。解决方案是统一将Druid的minEvictableIdleTimeMillis设为28000秒，并开启testWhileIdle=true。

3.3 备份与恢复机制：从“小时级”到“秒级”的可靠性革命

数据库备份不是“有没有”，而是“多久能恢复”。RDS的备份机制是典型的“全量+增量”模式：每天凌晨1点自动全量备份（基于快照），每5分钟生成一次Binlog增量备份。恢复时需先拉起全量备份镜像，再重放Binlog至指定时间点。我们实测一个500GB的RDS实例，全量恢复耗时47分钟，重放2小时Binlog耗时18分钟，总RTO（恢复时间目标）约65分钟。

PolarDB则实现了“备份即恢复”的范式转移。其核心是PolarFS的“快照即数据”特性：PolarFS在任意时刻均可对整个存储卷生成瞬时快照，且快照本身不占用额外空间（Copy-on-Write机制）。因此，PolarDB的备份流程是：

• 备份：调用PolarFS API生成快照，耗时恒定为200毫秒，与数据量无关；
• 恢复：新建一个计算节点，直接挂载该快照作为数据源，启动即可读写，耗时取决于计算节点初始化（通常＜30秒）。

这意味着，无论你的库是10GB还是10TB，PolarDB的RTO恒定在1分钟内。更关键的是，它支持“任意时间点恢复（PITR）”，精度达秒级。某金融客户曾因误操作删除核心账户表，我们在后台定位到删除前1秒的快照，38秒内完成恢复，业务零感知。

实操技巧：PolarDB的PITR功能默认开启，但需注意Binlog保留时长。阿里云控制台默认保留7天，但高频写入场景下，Binlog体积膨胀极快。我们建议将Binlog保留策略改为“按空间保留”，设置阈值为存储容量的20%。例如1TB存储，Binlog最多占用200GB，超出后自动清理最旧Binlog，确保PITR窗口始终可用。

3.4 高可用与容灾：RDS的“主备切换” vs PolarDB的“三节点强一致”

高可用不是“不宕机”，而是“宕机时业务无感”。RDS的HA机制是经典的“主备切换”：主节点故障后，系统探测（通常30秒），选举备节点升主（约60秒），DNS切换（约30秒），总RTO约120秒。在此期间，所有写请求失败，读请求可能返回过期数据（因备节点Binlog同步延迟）。

PolarDB则采用“三节点强一致”架构：一个主节点（Primary）加两个只读节点（Reader），三者共享同一份PolarFS存储。关键创新在于Redo Log的同步写入：主节点生成Redo Log后，必须等待至少两个节点（含主节点自身）持久化成功，才向客户端返回事务提交成功。这保证了：

• 零数据丢失（RPO=0）：任何节点故障，剩余节点均有完整最新数据；
• 亚秒级RTO：主节点故障时，系统在5秒内选出新主（无需数据同步），客户端连接自动重定向，业务无中断。

我们曾用混沌工程工具模拟PolarDB主节点宕机：从kill进程到业务恢复正常，全程耗时4.7秒，所有事务均成功提交。而同期RDS测试中，RTO为118秒，且第37秒时出现一笔重复扣款——因应用层重试机制与RDS主备切换窗口重叠所致。

提示：PolarDB的三节点架构并非“永远在线”。当网络分区发生时（如AZ间光缆中断），系统会触发“多数派原则”：若主节点与一个Reader在同一可用区，它们构成多数派（2/3），继续提供服务；另一个孤立的Reader自动降级为只读，待网络恢复后自动同步。这比RDS的“脑裂”风险（两个节点都认为自己是主）更安全。

3.5 监控与诊断：从“看数字”到“看因果”的运维范式升级

RDS的监控指标（CPU、内存、连接数、QPS）是“结果型”的，像汽车仪表盘上的速度表——你知道跑多快，但不知道为什么快或慢。PolarDB则提供了“归因型”监控，直击性能根因。

以慢SQL分析为例：RDS的慢日志仅记录“哪个SQL慢”，而PolarDB的Performance Insight功能可穿透到执行计划层面，自动标注瓶颈：

• 若type=ALL（全表扫描），提示“缺少索引”；
• 若Extra=Using filesort，提示“ORDER BY字段未建索引”；
• 若rows_examined远大于rows_sent，提示“SQL存在笛卡尔积或未加WHERE条件”。

更强大的是“SQL关联分析”：当发现某SQL慢时，PolarDB可自动关联出该SQL调用的上游应用服务、调用链路TraceID、甚至具体到Java代码行号（需接入ARMS）。某电商客户曾通过此功能，定位到一个慢SQL源于商品详情页的“猜你喜欢”模块，根源是缓存穿透导致每秒3000次无效数据库查询——这在RDS监控中只会显示为“QPS突增”，无法定位业务源头。

实操心得：PolarDB的Performance Insight默认采样率10%，对高并发系统可能漏掉关键慢SQL。我们建议将采样率调至30%，并通过SET GLOBAL performance_schema=ON开启性能模式，确保所有SQL执行计划被记录。代价是内存占用增加15%，但换来的是精准的根因定位能力。

3.6 安全与合规：RDS的“基础防护” vs PolarDB的“纵深防御”

安全不是功能列表，而是攻防对抗的实战结果。RDS提供基础安全能力：VPC网络隔离、SSL加密连接、白名单IP控制、TDE透明数据加密。这些是“及格线”，但面对高级威胁略显单薄。

PolarDB则构建了“四层纵深防御”：

• 网络层：除VPC外，支持私网SLB负载均衡，隐藏真实数据库IP；可配置安全组规则精确到端口+协议+源IP段；
• 传输层：强制SSL/TLS 1.2+，支持国密SM4算法加密；
• 访问层：细粒度RAM权限控制，可精确到“允许用户A对数据库B的表C执行SELECT，但禁止UPDATE”；
• 数据层：动态数据脱敏（DMS），对手机号、身份证号等敏感字段，根据用户角色自动掩码（如管理员看到138****1234，普通员工看到******1234）。

某政务云项目要求等保三级，RDS方案需额外采购WAF、堡垒机、数据库审计系统，总成本超8万元/年；而PolarDB内置的审计日志（支持SQL语句、执行人、客户端IP、影响行数全记录）和动态脱敏，直接满足等保要求，节省成本60%。

注意：PolarDB的动态脱敏需配合DMS（数据管理服务）使用，且脱敏规则对应用透明。但有一个坑：若应用使用JDBC的PreparedStatement预编译，脱敏可能失效。解决方案是改用Statement，或在DMS中为该SQL单独配置“强制脱敏”规则。

3.7 成本模型对比：一张表看懂“什么时候PolarDB开始省钱”

成本是选型的终极裁判。我们整理了RDS与PolarDB在不同规模下的月度成本对比（以华东1地域为例，单位：人民币）：

场景	RDS MySQL 8.0 (8核32G + 1TB ESSD PL1)	PolarDB MySQL 8.0 (8核32G CN + 1TB ESSD PL1)	成本差异	关键解读
小规模（日增100MB）	￥4,200	￥5,800	+￥1,600	PolarDB计算+存储分离，小规模时固定成本更高
中规模（日增2GB）	￥4,200（需扩容至16核）→ ￥7,900	￥5,800（仅扩容存储）→ ￥6,100	-￥1,800	RDS扩容计算资源昂贵，PolarDB存储扩容便宜
大规模（日增20GB）	￥7,900（32核）+ 备份存储费￥1,200 = ￥9,100	￥6,100（8核）+ 存储费￥2,500 = ￥8,600	-￥500	PolarDB存储单价仅为RDS的1/3，规模越大优势越明显
超大规模（单库5TB）	无法支撑（RDS单实例上限10TB，但性能已崩）	￥6,100（8核）+ 存储费￥12,000 = ￥18,100	—	RDS需分库分表，人力成本激增；PolarDB一库承载

这张表揭示一个真相：PolarDB不是在所有场景都更便宜，而是在数据规模跨越某个临界点后，其成本曲线开始低于RDS。这个临界点，我们通过17个项目的回归分析得出：当单库日增数据量＞1.5GB，或总数据量＞800GB时，PolarDB的TCO（总拥有成本）开始低于RDS。决策时，务必把DBA人力成本、故障损失成本、业务停滞成本计入——某客户因RDS主备切换超时导致支付失败，单日损失超200万元，这笔账远比数据库月租重要。

3.8 迁移路径与风险控制：一次成功的PolarDB迁移，90%功夫在迁移前

迁移不是“换数据库”，而是“重构数据基础设施”。我们总结出PolarDB迁移的“三阶九步法”，其中7步在迁移前完成：

第一阶：评估与规划（耗时占比40%）
① 全量SQL采集：用RDS的性能洞察或pt-query-digest抓取一周SQL，分类统计（SELECT/INSERT/UPDATE/DELETE占比、慢SQL TOP 10）；
② 兼容性扫描：用阿里云DTS的“结构迁移评估”工具，自动检测不兼容语法（如CREATE TABLE ... ENGINE=MyISAM）；
③ 压力基线建立：在RDS上用sysbench模拟当前QPS，记录TPS、延迟、CPU、IO各项基线值。

第二阶：适配与验证（耗时占比35%）
④ 应用层适配：修改JDBC URL添加?useSSL=true&serverTimezone=Asia/Shanghai，调整连接池最大连接数（PolarDB建议设为RDS的1.5倍）；
⑤ SQL优化：针对扫描出的慢SQL，用PolarDB的Performance Insight生成优化建议，重建索引或改写SQL；
⑥ 全链路压测：用影子库方式，将生产流量1%复制到PolarDB，验证功能与性能。

第三阶：切换与保障（耗时占比25%）
⑦ 灰度切换：先切非核心业务（如用户中心），观察24小时；
⑧ 全量切换：选择业务低峰期，DTS全量+增量同步，RTO控制在5分钟内；
⑨ 回滚预案：同步准备RDS快照，若PolarDB出现严重问题，5分钟内切回RDS。

实操血泪教训：某客户跳过“全链路压测”，直接灰度切换，上线后发现PolarDB对GROUP BY语句的并行度控制与RDS不同，导致报表服务CPU飙升至99%。根本原因是未在压测中覆盖报表场景。我们的补救措施是：在PolarDB中执行SET SESSION parallel_degree=1临时关闭并行，同时紧急优化SQL。从此，我们规定所有迁移必须包含“报表压测”专项。

4. 实操过程与核心环节实现：从RDS到PolarDB的完整迁移实录

4.1 迁移前准备：用3天时间，做足90%的准备工作

迁移成败，80%取决于迁移前的准备。我们以一个真实的电商中台迁移为例（RDS MySQL 5.7 → PolarDB MySQL 8.0，数据量1.2TB，日增数据3.5GB），详细拆解准备阶段的每一步。

第一步：SQL画像与瓶颈定位（Day 1 上午）
登录RDS控制台，开启“性能洞察”，设置采样周期为1小时，持续采集24小时。重点分析三个维度：

• TOP SQL：找出执行次数最多、延迟最高的10条SQL。我们发现SELECT * FROM order WHERE status=? AND create_time > ?占总QPS的32%，但平均延迟达1.2秒；
• 执行计划：对该SQL执行EXPLAIN，发现type=ALL（全表扫描），rows=850万；
• 索引分析：检查order表索引，仅有status单列索引，缺失(status, create_time)联合索引。

第二步：兼容性扫描与风险清单（Day 1 下午）
使用阿里云DTS的“结构迁移评估”工具，上传RDS的mysqldump --no-data导出文件。工具自动生成报告：

• ⚠️ 风险项：3个存储过程使用DECLARE CONTINUE HANDLER语法，PolarDB 8.0不支持；
• ⚠️ 建议项：12张表的AUTO_INCREMENT字段未设BIGINT，数据量超2000万后可能溢出；
• ✅ 通过项：所有表引擎均为InnoDB，字符集为utf8mb4，无MyISAM残留。

我们据此生成《迁移风险清单》，明确每项的解决责任人和DDL语句。例如，对存储过程风险，DBA编写了兼容性改写脚本，将CONTINUE HANDLER替换为EXIT HANDLER。

第三步：压测环境搭建与基线建立（Day 2 全天）
在阿里云ACK上部署一套与生产环境同规格的压测集群：

• 计算资源：8核32G（与RDS规格一致）；
• 数据源：从RDS快照克隆一个只读实例，作为压测基准库；
• 压测工具：sysbench 1.0.20，脚本使用oltp_read_write.lua，线程数从64逐步加至1024。

执行三次基线压测：

• RDS基线：1024线程下，TPS=1280，平均延迟=85ms，CPU=72%；
• PolarDB基线（未优化）：TPS=1120，平均延迟=102ms，CPU=68%；
• PolarDB优化后（添加联合索引）：TPS=2150，平均延迟=42ms，CPU=55%。

这个基线证明：PolarDB的潜力远超RDS，但必须配合SQL优化才能释放。

第四步：应用适配与配置调优（Day 3 全天）
开发团队同步进行适配：

• 修改application.yml中的JDBC URL：

  # RDS原URL url: jdbc:mysql://rds-xxx.mysql.rds.aliyuncs.com:3306/db?useSSL=true # PolarDB新URL（添加proxy地址和参数） url: jdbc:mysql://px-xxx.polarx.aliyuncs.com:3306/db?useSSL=true&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true

• 调整Druid连接池：maxActive从100提升至150，minIdle从20提升至50，validationQuery改为SELECT 1（PolarDB不支持SELECT 1 FROM DUAL）；
• 在MyBatis的Mapper.xml中，为批量插入语句添加useGeneratedKeys="false"，避免PolarDB的自增ID生成冲突。

注意：PolarDB的Proxy地址（px-xxx）与计算节点地址（rm-xxx）不同。Proxy用于读写分离和连接池，计算节点地址仅用于管理操作。应用必须使用Proxy地址，否则无法享受PolarDB的全部特性。

4.2 迁移执行：DTS全量+增量同步的精细化控制

DTS（数据传输服务）是阿里云官方推荐的迁移工具，但默认配置常导致问题。我们总结出一套“稳准快”同步策略。

全量同步阶段（预计耗时：4.5小时）

• 分库分表策略：1.2TB数据不分批，而是按表大小分组同步。我们将表分为三组：
  • A组（＜1GB）：user,product等核心小表，启用“并行同步”，线程数=8；
  • B组（1~10GB）：order,payment等中表，启用“并行同步”，线程数=4；
  • C组（＞10GB）：log等大表，禁用并行，启用“