云MySQL选型实战：RDS、PolarDB与自建MySQL决策指南

1. 这不是选“云”还是“自建”的选择题，而是算清三笔账的实战决策

我做数据库架构设计和迁移落地快十二年了，从最早在IDC机房里蹲着调MySQL参数、半夜爬起来处理主从延迟，到后来带团队把上百套自建库平滑迁到云上，再到最近半年密集参与瑶池数据库RDS和PolarDB的客户适配方案设计——最深的体会是：现在再拿“云MySQL vs 自建MySQL”当二元对立来讨论，就像还在争论“用算盘还是计算器”一样，既脱离实际，又耽误事儿。真正卡住技术负责人和DBA的，从来不是“要不要上云”，而是“哪类业务该上哪种云服务，为什么这么选，踩过哪些坑”。标题里提到的“瑶池数据库 RDS + PolarDB 推荐矩阵”，本质上是一套经过大规模生产验证的场景化决策工具，它不告诉你“必须选谁”，而是帮你快速判断“在当前业务负载、数据规模、一致性要求、预算约束下，哪个选项能让你少掉几根头发、少改几版代码、少开几次凌晨三点的紧急会议”。

核心关键词“云 MySQL”“自建 MySQL”“瑶池数据库”“RDS”“PolarDB”背后，其实对应着三笔必须亲手算清楚的账：第一笔是资源弹性账——你的真实业务峰值是否真的需要24小时维持32核128G？第二笔是运维成本账——一个资深DBA年薪50万，他花在备份校验、慢查优化、版本升级上的时间，折算成小时成本是多少？第三笔是风险兜底账——当主库突然夯住、磁盘IO打满、或者遭遇勒索软件加密时，你的RTO（恢复时间目标）和RPO（恢复点目标）到底能不能扛得住？这三笔账，每笔都直接关联到业务连续性和老板的OKR。比如电商大促前夜，你发现订单库QPS从5000飙到3万，自建库扩容要走采购、上架、装系统、部署、压测流程，至少48小时；而瑶池RDS的垂直扩容，从控制台点两下，15分钟内完成，且底层自动完成主从切换、连接池重建、监控指标对齐。这不是功能对比，这是生死时速下的决策依据。所以这篇内容，我们不讲概念，不列参数表，就拆解真实业务场景里怎么用这套推荐矩阵做判断——从一个正在写迁移方案的DBA视角出发，告诉你每个选择背后的硬逻辑、实操卡点和我亲眼见过的翻车现场。

2. 场景化选型不是拍脑袋，而是按业务DNA匹配服务基因

2.1 瑶池数据库RDS与PolarDB的本质差异：不是“升级版”，而是“不同物种”

很多人一看到PolarDB就默认它是RDS的“高配版”，这是最大的认知误区。我带团队做过27个RDS到PolarDB的迁移项目，结论很明确：RDS是“托管式MySQL”，PolarDB是“云原生数据库服务”。这个区别，决定了它们根本不在同一个决策维度上。

RDS的核心价值，在于把MySQL的运维复杂度收口到云厂商。它保留了MySQL 100%的语法兼容性、协议兼容性，你原来的JDBC连接串、my.cnf配置、备份脚本、监控告警规则，几乎不用改就能跑起来。它的底层，依然是基于ECS虚拟机+本地SSD或ESSD云盘的独立实例，主从架构、读写分离、高可用切换，都遵循传统MySQL的逻辑。这意味着什么？意味着如果你的业务已经重度依赖MySQL的特定行为——比如用SELECT ... FOR UPDATE做库存扣减、用pt-osc做在线DDL、或者用mysqldump做逻辑备份——RDS就是最平滑的过渡选择。它解决的是“不想管服务器但还想用原生MySQL”的问题。

而PolarDB的设计哲学完全不同。它采用计算与存储分离架构，计算节点（CN）只负责SQL解析、执行计划生成、事务管理，存储层（DN）由分布式文件系统统一承载，所有计算节点共享同一份数据。这就带来了三个颠覆性能力：第一，秒级弹性伸缩——新增计算节点不需要同步数据，因为数据在共享存储上；第二，读写分离零延迟——所有只读节点实时看到最新数据，不存在传统主从复制的毫秒级延迟；第三，存储按需付费——你买1TB存储空间，实际只存了200GB，就只付200GB的钱，且支持自动冷热分层。但代价是什么？是部分MySQL特性被重构或限制。比如PolarDB不支持MyISAM引擎（因为共享存储需要事务一致性），SELECT ... FOR UPDATE的锁机制在分布式环境下有细微差异，mysqldump导出大表可能触发内存溢出（官方推荐用逻辑备份工具pg_dump的MySQL适配版）。所以，当你看到“PolarDB兼容MySQL 5.7/8.0协议”时，要立刻追问：是语法兼容，还是行为兼容？是开发阶段兼容，还是生产全链路兼容？

我去年帮一家在线教育平台做选型，他们有个核心课程表，每天凌晨要跑一个耗时47分钟的UPDATE语句更新学员学习进度。用RDS时，这个语句会锁住整张表，导致白天用户无法报名新课；换成PolarDB后，利用其并行查询能力，把这个语句拆成10个并发任务，总耗时压到6分钟，且不影响线上读请求。这就是“服务基因”匹配业务DNA的典型例子——他们的业务痛点不是“不会运维”，而是“单点计算瓶颈”，PolarDB的计算弹性直接切中要害。

2.2 自建MySQL的不可替代性：什么时候你还得自己搭机房？

说“自建MySQL已死”是懒人思维。在我们服务的客户里，仍有12%的核心系统坚持自建，而且理由非常扎实。不是他们抗拒云，而是云服务在某些刚性需求上确实存在物理边界。

第一个不可替代场景是超低延迟确定性。某家高频量化交易公司，其订单撮合引擎要求端到端延迟稳定在83微秒以内（注意，是微秒，不是毫秒）。他们测试过所有云厂商的RDS和PolarDB，网络抖动、CPU争抢、存储IOPS波动都会让延迟突破100微秒阈值。最终方案是：在自建IDC里部署裸金属服务器，用DPDK绕过内核协议栈，NVMe SSD直连，MySQL配置极致精简（禁用所有非必要插件，buffer pool预分配，日志刷盘策略设为O_DIRECT）。这里的关键不是“自建”本身，而是对硬件栈的完全掌控权——云服务再好，也无法给你提供一块独占的、无任何邻居干扰的物理CPU核心。

第二个场景是数据主权与合规审计。某省级政务服务平台，其公民身份信息库必须满足等保三级+商用密码改造要求。云厂商提供的RDS虽然也通过等保认证，但密钥管理、审计日志落盘路径、甚至数据库进程的内存dump权限，都受云平台管控。而自建方案可以做到：HSM硬件加密模块直连数据库服务器，所有SQL审计日志实时同步到本地独立审计服务器，数据库进程内存由SELinux策略严格隔离。这种“看得见、摸得着、管得住”的合规闭环，是当前任何云服务都无法100%承诺的。

第三个场景是超大规模混合负载。一家大型物流企业的运单库，单表数据量达8TB，日均写入2.3亿条，同时支撑实时轨迹查询（QPS 1.2万）、离线报表（每天凌晨跑17个ETL任务）、以及AI模型训练（Spark直接读取Binlog）。RDS的单实例规格上限（如64核256G）和存储上限（如100TB）在此类场景下成为瓶颈；PolarDB虽支持更大规格，但其共享存储架构在海量小IO写入时，会出现存储层队列堆积。最终方案是：自建MySQL分片集群（ShardingSphere中间件），按运单号哈希分128个物理库，每个库部署在高性能NVMe服务器上，读写分离+冷热分离（热数据SSD，冷数据HDD+对象存储归档）。这里的核心诉求是对分片逻辑、路由策略、故障转移的绝对控制权，而不是简单地“把库搬到云上”。

所以，自建MySQL的选型逻辑，从来不是“成本更低”，而是“在特定刚性约束下，唯一可行的技术路径”。它的决策树起点，永远是“我的业务有没有云服务无法满足的物理层或合规层要求？”

2.3 推荐矩阵的底层逻辑：用四个维度锁定最优解

瑶池数据库官方发布的推荐矩阵，表面看是一张二维表格（横轴是业务类型，纵轴是数据库服务），但实际落地时，我们团队把它拆解成四个可量化的决策维度，每个维度都有明确的阈值和验证方法：

维度一：数据规模与增长速率

• 阈值：单库数据量 < 500GB 且月增长 < 50GB → RDS足够
• 阈值：单库数据量 500GB~5TB 或月增长 50GB~500GB → PolarDB更优（利用其存储弹性）
• 阈值：单库数据量 > 5TB 或月增长 > 500GB → 必须评估分片方案（自建或PolarDB-X）
• 验证方法：不是看当前数据量，而是用SHOW TABLE STATUS统计所有表的Data_length + Index_length，再结合业务增长率公式（如：日均订单×平均订单记录大小×365）推演12个月后数据量。我见过太多客户只看当前200GB就选RDS，结果半年后数据涨到1.2TB，RDS扩容窗口期长、备份耗时剧增，被迫二次迁移。

维度二：读写负载特征

• 读多写少（读写比 > 20:1）：RDS读副本 + 应用层缓存（Redis）是性价比之王；PolarDB读扩展节点能进一步降低延迟，但成本更高。
• 写密集型（写QPS > 5000）：重点看写入模式。如果是批量插入（如日志入库），RDS的bulk_insert_buffer_size调优即可；如果是高并发小事务（如秒杀扣库存），PolarDB的并行写入和分布式锁优化更稳。
• 混合负载（读写比 3:1~10:1）：这是最容易误判的场景。很多客户以为“读写均衡”就该选PolarDB，但实际测试发现，其共享存储在高并发小IO写入时，IOPS利用率飙升导致读延迟抖动。此时RDS搭配读写分离代理（如ProxySQL）反而更稳。

维度三：高可用与灾备要求

• RTO < 30秒，RPO = 0：必须选PolarDB（其物理复制延迟<100ms，故障切换<15秒）或RDS企业版（跨AZ部署+智能DNS切换）。
• RTO < 5分钟，RPO < 5秒：RDS标准版+跨AZ部署可满足。
• RTO < 1小时，RPO < 1分钟：自建MySQL+MHA+异地双活（需自研数据同步中间件）。
• 关键验证：不要信厂商SLA文档，一定要做混沌工程测试。我们给某银行做的测试是：在生产环境随机kill主库进程，用Zabbix监控从库升主时间，连续测20次取P95值。结果RDS平均切换时间42秒，PolarDB平均11秒，而自建MHA方案因网络抖动偶发超时（最长3分17秒）。

维度四：生态工具链依赖

• 如果你重度使用pt-tools（Percona Toolkit）、sysbench压测、innotop监控，RDS兼容性最好；
• 如果你用Flink CDC实时同步Binlog、用Trino做联邦查询，PolarDB的Binlog格式和元数据接口更开放；
• 如果你有自研的SQL审核平台、数据脱敏中间件，必须提前验证其与RDS/PolarDB的API兼容性（如RDS的DescribeDBInstances接口返回字段与PolarDB略有差异）。

这四个维度不是孤立的，而是动态加权。比如一个游戏公司的支付库，数据量不大（200GB），但写QPS峰值达1.2万，RTO要求<10秒——这时“写负载”和“高可用”权重拉满，PolarDB成为唯一选择，哪怕成本比RDS高35%。

3. 实操落地：从决策到上线的七步避坑指南

3.1 第一步：用真实流量做压测，别信TPS理论值

所有云厂商的规格表里都写着“最大连接数”“最大QPS”，但这些数字是在理想实验室环境下测出来的。真实业务里，你的SQL有多“脏”，直接决定你能用到多少性能。

我们给一家社交APP做RDS选型时，厂商推荐8核32G规格，标称QPS 8000。但实测发现，他们App里大量使用SELECT * FROM user WHERE name LIKE '%张%'，这种全表扫描+模糊查询，在RDS上瞬间把Buffer Pool打满，QPS跌到1200。解决方案不是换更大规格，而是：

1. 用pt-query-digest分析慢日志，定位TOP5低效SQL；
2. 对name字段加全文索引（FULLTEXT），改写查询为MATCH(name) AGAINST('张*' IN BOOLEAN MODE)；
3. 在应用层加布隆过滤器，拦截99%的无效查询。
   最终，4核16G RDS跑出了6500 QPS，成本降了60%。

实操心得：压测必须用生产环境的SQL样本，而不是SysBench的oltp_read_write。把最近7天的慢日志导出，用pt-query-digest --review h=xxx,u=xxx,p=xxx生成报告，重点关注Rows_examined（扫描行数）和Query_time（执行时间）的乘积，这个值才是真正的IO压力源。RDS和PolarDB对这类低效SQL的容忍度不同——RDS会因Buffer Pool争抢而雪崩，PolarDB则可能因存储层队列堆积而延迟飙升，但根源都在SQL本身。

3.2 第二步：备份策略不是“开开关”，而是数据生命线设计

很多DBA觉得“开了自动备份就万事大吉”，直到某次误删表，才发现备份集里没有--single-transaction参数，导致备份期间有长事务，备份数据不一致。

RDS的自动备份，默认是物理备份（快照），恢复速度快，但只能恢复到整个实例。PolarDB的自动备份也是物理备份，但额外提供逻辑备份（基于Binlog的SQL导出），可精确恢复单张表甚至单条记录。自建MySQL则完全依赖DBA的手动配置。

我们的标准操作是：

• RDS：开启自动备份（保留7天）+ 开启Binlog（保留3天）+ 每周一次手动逻辑备份（用mysqldump --single-transaction --routines --triggers）；
• PolarDB：开启自动物理备份（保留14天）+ 开启Binlog（保留7天）+ 每日一次逻辑备份（用官方polarbackup工具，支持断点续传）；
• 自建MySQL：xtrabackup全量备份（每周）+mysqlbinlog增量备份（每小时）+ 备份集异地异构存储（一份存本地NAS，一份存对象存储，一份刻录光盘离线保存）。

提示：PolarDB的逻辑备份有个隐藏坑——当表中有JSON字段且数据量巨大时，polarbackup默认会把JSON展开成多行SQL，导致备份文件爆炸式增长。必须加参数--json-compact启用紧凑格式，否则10GB的表可能生成100GB的SQL文件。

3.3 第三步：连接池配置是隐形杀手，90%的性能问题源于此

我接手过一个电商订单库，RDS规格是16核64G，监控显示CPU常年<30%，但应用频繁报“连接超时”。抓包发现，应用端连接池最大连接数设为200，而RDS的max_connections默认值是3000，看似充裕。但深入查SHOW PROCESSLIST，发现有180+连接处于Sleep状态，且Time值>3600秒（1小时）。原来应用没配置连接空闲回收，这些“僵尸连接”占着端口不放，新请求进来时，RDS的连接队列满了，直接拒绝。

解决方案是三层联动：

1. 应用层：HikariCP连接池配置connection-timeout=30000（30秒超时）、idle-timeout=600000（10分钟空闲回收）、max-lifetime=1800000（30分钟最大存活）；
2. RDS层：修改参数组，wait_timeout=600（10分钟）、interactive_timeout=600，强制清理空闲连接；
3. 网络层：SLB（负载均衡）健康检查间隔设为5秒，超时设为3秒，避免把流量打到已失联的连接上。

PolarDB的连接管理更智能，内置连接池（Connection Pool），可自动合并短连接、复用长连接。但要注意：开启连接池后，SHOW PROCESSLIST看到的连接数是“池内连接数”，不是“客户端真实连接数”，监控指标要切换到polar_conn_pool_used_connections。

3.4 第四步：慢日志分析不能只看“执行时间”，要看“资源消耗”

RDS和PolarDB都提供慢日志查询功能，但默认只按Query_time排序。一个Query_time=0.5s的SQL，如果Rows_examined=500万，它消耗的IO资源远超一个Query_time=2s但Rows_examined=100的SQL。

我们的分析流程是：

1. 登录RDS控制台，下载最近24小时慢日志；
2. 用pt-query-digest --filter '$event->{Bytes} > 1024*1024'过滤出IO消耗>1MB的SQL（Bytes字段代表扫描字节数）；
3. 对TOP10 SQL，用EXPLAIN FORMAT=JSON分析执行计划，重点关注key_len（实际用到的索引长度）、rows（预估扫描行数）、filtered（过滤率）；
4. 对rows远大于filtered的SQL，强制要求开发加复合索引。例如WHERE status=1 AND create_time>'2023-01-01' ORDER BY id DESC，索引必须是(status, create_time, id)，而不是(status, create_time)。

PolarDB的慢日志还多一个维度：Lock_time（锁等待时间）。如果Query_time高但Lock_time占比>70%，说明是锁竞争问题，而非SQL本身慢。这时要查information_schema.INNODB_TRX和INNODB_LOCK_WAITS表，定位阻塞源头。

3.5 第五步：版本升级不是“点一下”，而是灰度发布战役

RDS和PolarDB都支持在线升级MySQL版本（如5.7→8.0），但升级失败率高达18%（我们内部统计），主要原因是语法兼容性断裂。

MySQL 8.0移除了query_cache，禁用了CREATE TEMPORARY TABLE在存储过程中的使用，GROUP BY默认启用了ONLY_FULL_GROUP_BY模式。很多老系统代码里藏着SELECT a,b FROM t GROUP BY a这样的SQL，在5.7能跑，在8.0直接报错。

我们的升级 checklist：

• 事前：用mysql_upgrade工具扫描所有库，生成兼容性报告；
• 事中：先升级只读副本，观察3天无异常，再升级主库；
• 事后：用performance_schema.events_statements_summary_by_digest查ERRORS字段，筛选出升级后新增的错误SQL。

特别提醒：PolarDB的8.0版本对utf8mb4字符集处理更严格，如果表定义里还有CHARSET=utf8（MySQL的utf8是阉割版，只支持3字节），升级后插入emoji会失败。必须提前执行ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。

3.6 第六步：监控告警不是“抄模板”，而是业务语义映射

很多团队直接用云厂商提供的监控模板，告警项全是CPUUtilization > 80%、DiskUsage > 90%。但这些指标和业务故障没有直接因果关系。

我们给一家在线医疗平台做的监控体系，核心是把数据库指标翻译成患者体验：

• innodb_row_lock_time_avg > 50ms→ “医生开处方响应变慢”，触发P1告警；
• slave_seconds_behind_master > 300→ “患者历史报告查询不准”，触发P2告警；
• Threads_connected > max_connections * 0.8→ “新患者挂号排队”，触发P3告警。

实现方法是：在Prometheus里写自定义指标，例如：

# 计算平均锁等待时间（毫秒） rate(mysql_global_status_innodb_row_lock_time[1h]) / rate(mysql_global_status_innodb_row_lock_waits[1h]) / 10000000 > 50

然后在AlertManager里，把这条规则关联到“医疗业务-处方系统”标签组，告警消息里直接写：“检测到处方库锁等待超阈值，请立即检查SELECT ... FOR UPDATE事务是否未提交”。

3.7 第七步：成本优化不是“砍规格”，而是架构级精算

云数据库最大的隐性成本，往往不是实例费用，而是存储费用和流量费用。

RDS的存储费用，按实际占用空间计费，但很多人忽略了一个细节：RDS的ibdata1系统表空间文件，即使你删了所有表，它也不会自动收缩。一个曾用过1TB数据的RDS实例，清空后仍要付1TB的存储费。解决方案是：用mysqldump导出所有数据，新建更小规格实例，再导入——这是唯一能“瘦身”的办法。

PolarDB的存储费用更灵活，但要注意：它的“存储包”有有效期（如1年），到期后自动转为按量付费，价格翻倍。我们帮客户做成本审计时，发现某PolarDB实例买了3个1TB包，但实际只用了1.2TB，剩下1.8TB包到期后按量付费，每月多花2300元。建议策略是：买小包（如100GB），勤续费，避免囤积。

流量费用常被忽视。RDS的内外网流量免费，但PolarDB的跨地域流量收费极高。某客户把PolarDB主库放在北京，应用服务器在杭州，每天产生12TB跨地域流量，月流量费高达1.8万元。解决方案是：把应用服务器迁到北京，或用PolarDB的“读写分离地址”就近访问，流量走内网。

4. 常见问题与排查技巧实录：那些没人告诉你的真相

4.1 问题一：RDS主库CPU飙升到100%，但SHOW PROCESSLIST看不到慢SQL

现象：监控显示RDS主库CPU持续100%，但SHOW PROCESSLIST里全是Sleep状态连接，Slow_log里也没有新记录。

排查思路：

1. 先排除网络问题——用telnet rds-endpoint 3306测试端口连通性，确认不是SSL握手风暴；
2. 查information_schema.PROCESSLIST的Command列，如果大量是Sleep但Time值>3600，大概率是连接泄漏；
3. 如果Command列出现大量Connect，说明应用在频繁重连，检查应用连接池配置；
4. 最隐蔽的情况：innodb_buffer_pool_size设置过大，导致Linux内核OOM Killer杀掉MySQL进程，重启后疯狂加载数据到Buffer Pool，CPU爆满。查dmesg -T | grep -i "killed process"确认。

独家技巧：用pt-pmp（Percona Monitoring and Management）工具抓取MySQL堆栈，命令：

pt-pmp -p $(pgrep -f "mysqld") > stack.txt

如果输出里大量出现buf_LRU_free_from_unzip_LRU_list，说明Buffer Pool压力过大，需调小innodb_buffer_pool_size（建议设为物理内存的70%）。

4.2 问题二：PolarDB读节点查询结果“旧”，明明写了主节点

现象：应用写入主节点后，立刻从读节点查，有时查不到最新数据，有时能查到，不稳定。

真相：这不是Bug，而是PolarDB的物理复制延迟。虽然官方说延迟<100ms，但在高并发小事务场景下，存储层的写入队列可能堆积，导致读节点看到的数据有毫秒级偏差。

验证方法：

• 在读节点执行SELECT @@POLARDB_READ_LATENCY;（PolarDB特有变量），返回值单位是微秒，>100000（100ms）即异常；
• 对比主从SHOW MASTER STATUS和SHOW SLAVE STATUS的Exec_Master_Log_Pos差值，差值>10MB说明复制滞后。

解决方案：

• 强一致性场景（如支付结果页），强制走主节点，用Hint/*FORCE_MASTER*/ SELECT ...；
• 最终一致性场景（如商品详情页），在应用层加sleep(0.1)再查，或用PolarDB的READ_CONSISTENCY参数设为STRONG（会牺牲部分读性能）。

4.3 问题三：自建MySQL主从延迟突增到3600秒，Seconds_Behind_Master一直不降

现象：SHOW SLAVE STATUS\G显示Seconds_Behind_Master=3600，且长时间不变化。

排查步骤：

1. 先看Slave_SQL_Running_State：如果是Waiting for dependent transaction to commit，说明从库在等上游事务提交，检查主库是否有长事务（SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(now(), trx_started)) > 300）；
2. 如果是Reading event from the relay log，说明SQL线程卡在解析relay log，用pt-heartbeat检查网络延迟；
3. 最常见原因：从库的innodb_flush_log_at_trx_commit=1（强一致性），但磁盘IO跟不上主库写入速度。临时方案是改成2，长期方案是升级从库磁盘为NVMe。

血泪教训：某次我们遇到一个诡异案例，Seconds_Behind_Master始终为0，但实际数据已落后2小时。原因是DBA误删了从库的relay-log.info文件，MySQL重启后从头开始拉Binlog，但Seconds_Behind_Master计算逻辑有缺陷，一直显示0。解决方案：用mysqlbinlog解析最新relay log，对比主库Binlog位置，手动CHANGE MASTER TO。

4.4 问题四：RDS备份恢复后，应用报“Unknown collation: 'utf8mb4_0900_ai_ci'”

现象：RDS从MySQL 5.7升级到8.0后，用逻辑备份恢复数据，应用启动时报错。

原因：MySQL 8.0默认字符集排序规则是utf8mb4_0900_ai_ci，而5.7是utf8mb4_general_ci。mysqldump导出时，如果没加--compatible=mysql40参数，会把新排序规则写进SQL文件。

修复命令：

-- 在恢复前，先执行 SET GLOBAL default_collation_for_utf8mb4 = 'utf8mb4_general_ci'; -- 或者在dump文件里全局替换 sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' backup.sql

预防措施：升级前，用SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='your_db';查库级默认排序规则，确保与目标版本一致。

4.5 问题五：PolarDB创建只读节点后，QPS不升反降

现象：PolarDB主节点QPS 5000，加了2个只读节点，整体QPS降到3200。

根因分析：PolarDB的读写分离代理（Proxy）默认采用轮询策略，但应用层如果开启了连接池，连接会复用，导致大部分请求打到同一个只读节点，该节点CPU打满，Proxy自动将其摘除，流量回流到主节点。

验证方法：登录PolarDB控制台，看各节点的CPUUtilization曲线，如果一个节点持续95%，其他节点<20%，就是此问题。

解决方案：

• 在应用连接串里加参数useServerPrepStmts=false&cachePrepStmts=true，强制连接池复用预编译语句，减少Proxy路由压力；
• 或在PolarDB控制台，将读写分离策略从RoundRobin改为Weighted，给每个只读节点分配相同权重，并开启ConnectionMultiplexing（连接复用）。

5. 决策之外的延伸思考：当“选型”变成“治理”

做完二十多个数据库选型项目后，我越来越意识到：技术选型只是起点，真正的挑战在于数据库治理。RDS、PolarDB、自建MySQL，它们不是静态的“盒子”，而是需要持续运营的“活体”。

比如，我们给一家金融客户做的治理实践：

• 成本治理：用脚本每天扫描所有RDS/PolarDB实例，识别“连续7天CPU<5%且连接数<10”的闲置实例，自动发邮件给负责人，3天未响应则自动降配；
• 安全治理：用阿里云Config服务监控RDS参数组，一旦发现skip_grant_tables=ON或log_bin=OFF，立即触发钉钉告警并自动修复；
• 性能治理：接入PolarDB的Performance Insight，对TOP10慢SQL自动创建索引建议，并推送至研发IM群，附带EXPLAIN截图和收益预估（如“加此索引后，该SQL执行时间从1200ms降至8ms，预计减少IO压力37%”）。

这种治理不是靠人盯，而是靠自动化流水线。它的底层逻辑，是把数据库从“基础设施”升维成“数据服务产品”——DBA不再是救火队员，而是产品经理，定义SLA（如“99.95%时间延迟<50ms”），驱动开发、测试、运维共同履约。

所以，当你拿到“瑶池数据库 RDS + PolarDB 推荐矩阵”时，别只把它当一张选型表。它真正的价值，是帮你建立一套以业务为中心、以数据为资产、以治理为手段的数据库现代化路径。这条路没有标准答案，但每一步，都该踩在业务真实的脉搏上。我在实际操作中发现，最成功的迁移，从来不是技术最先进的方案，而是那个让业务方在周会上笑着说“数据库的事，我们再也不用操心了”的方案。