我从MySQL 5.5时代就开始在生产环境里折腾数据库运维一路看着它从单机、主从、分库分表走到云原生。最近几年帮不少团队做过MySQL数据库选型几乎每个团队都会问同一个问题自建MySQL是不是更省RDS和PolarDB到底选哪个这个问题没法用一句“看情况”糊弄过去因为答案直接关系到后面两三年的运维成本、迭代速度和大促扛压能力。所以我一直建议把这个问题拆成“场景矩阵”来看今天这篇就把瑶池数据库RDS和PolarDB的选型逻辑完整梳理一遍帮你按自己的业务阶段对号入座。1. 先算一笔账自建MySQL真的更省钱吗1.1 硬件、网络与基础软件费用很多人一听到“自建”脑子里浮现的就是“开源等于免费”。MySQL社区版确实免费但这只是账面上最浅的一层。你一旦决定自建就要先回答一个问题机器放哪放在公司机房机房机柜费用、电力费用、网络带宽费用要算放在公有云上买ECS本质上也还是在给云厂商付费。以一套中等规模业务为例主库至少要8核32G的配置备库再一台同样的机器外加至少500G高性能云盘做数据存储备份再单独丢到对象存储。这套基础配置按月测算单纯资源费就是一笔不小的固定支出。而且数据库对磁盘性能极其敏感云盘想上高IOPS单价会明显往上跳。更隐蔽的是资源利用率问题。自建环境为了留出故障切换和业务峰值余量CPU和内存通常只能用到60%到70%剩下全在空转。也就是说你花钱买的资源里有三成左右是养着“以防万一”的。云数据库虽然也是按规格收费但规格可以随时升、随时降不会让你长期为一个永远用不上的高配买单。1.2 人力运维成本这部分很少被写进预算表却是自建MySQL真正的大头。我自己早期管过一套主从架构光日常的备份脚本、监控告警、日志清理就能占掉每周不少时间。如果你不想完全裸奔那至少要做下面这些事定期全量备份通常用mysqldump或Percona XtraBackup写脚本还要定时校验备份文件能不能正常恢复。搭建主从复制处理复制中断、主从延迟、数据一致性校验。配置高可用方案像MHA、Orchestrator再搞一套VIP漂移切换时还会有脑裂风险。MySQL小版本升级、安全补丁修复都要申请停机窗口白天基本不敢动。慢查询优化、索引治理、容量规划这些技术活一个都不能少。把这些工作折算成人天一年下来非常可观。如果公司没有专职DBA靠业务研发兼职维护那更是隐患重重——业务代码还没写完半夜还要爬起来救数据库。而选择云数据库上面这一长串事基本都被平台托管了你只需要把精力放在表结构和SQL优化上。1.3 故障与数据丢失的隐性成本这年头数据比机器贵。自建环境里我见过凌晨磁盘被慢查询日志打满导致主库宕机的见过备份脚本因为目录权限问题悄悄失败、连续跑了一个月才发现备份全是空的还见过主从切换演练时VIP漂移失败、业务中断半小时的。这些故障的恢复时间完全取决于值班人员的处理经验。而在云数据库这一侧RDS默认就有自动主备切换能力探测到主库异常会自动把连接漂移到备库SLA有明确承诺。备份也是自动做的支持按时间点恢复能把数据找回粒度精确到秒级。我把这三个维度的差异整理成一张表方便大家直观对比对比项自建MySQLRDS MySQLPolarDB MySQL版初始成本硬件/机器投入高按规格付费按规格付费运维人力需要专职DBA或研发兼职平台托管几乎为零平台托管几乎为零高可用能力自己搭主从MHA风险高自动主备切换SLA明确存储计算分离一写多读自动容灾备份恢复脚本备份需手动验证自动备份时间点恢复自动备份时间点恢复弹性扩展扩机器要重新迁移数据升配降配相对方便秒级扩展只读节点最大容量远高于单机这张表不是让你看完就立刻放弃自建而是提醒你自建MySQL真正“便宜”的前提是数据量小、业务允许停机、团队里有能顶住压力的人。一旦业务规模上来隐性成本会迅速超过云数据库的费用。2. 云数据库两大主力RDS MySQL 与 PolarDB 的架构差异2.1 RDS MySQL最省心的“原厂托管”阿里云上的RDS MySQL可以直接理解为“原生MySQL的托管版本”。无论你是从自建数据库迁移上来还是新项目直接创建它都保留了你在社区版MySQL里熟悉的那套东西InnoDB存储引擎、SQL语法、索引逻辑、事务隔离级别基本是零学习成本。RDS MySQL的核心价值在运维托管。默认一主一备架构主库故障自动切换每天自动做全量备份binlog持续备份随时可以按时间点恢复到任意秒级监控告警、慢查询分析、性能洞察这些原本需要DBA自己搭一套的工具控制台里直接就有。规格方面分通用型和独享型预算有限的场景选通用型即可性能敏感的核心库再上独享型。对我个人而言RDS MySQL最大的意义是“稳”。它不会给你什么惊喜但也很少给你惊吓。如果你的业务是传统的订单系统、内容管理系统、内部OA数据结构固定、QPS不高不低、团队又不想在数据库运维上投入精力RDS MySQL是那个不会出错的选择。2.2 PolarDB存储计算分离的云原生架构PolarDB MySQL版就不是简单的“托管MySQL”了它的底层架构是存储计算分离计算节点只负责SQL解析和执行数据统一存放在底层的分布式存储集群里。听起来复杂实际收益非常直接。第一个收益是容量。传统自建MySQL或RDS的存储上限受单个实例限制数据量到了几个TB就要开始考虑分库分表。PolarDB的存储池化之后单库容量可以达到百TB级别绝大多数业务根本不用走到分库分表那一步。第二个收益是扩展。PolarDB默认一写多读写节点只有一个只读节点可以根据业务压力快速增加。因为数据是共享存储新加一个只读节点不需要把全量数据重新拷贝一遍分钟级就能完成扩展。相比自建主从要重新搭建、追赶binlog体验完全不在一个层级。第三个收益是低延迟的物理复制。传统MySQL主从复制是逻辑复制执行SQL或应用binlog事件延迟容易飙升PolarDB的只读节点通过物理复制Redo日志同步数据主从延迟可以压到非常低这让“读写分离”从理论变成了真正可落地的方案。2.3 兼容性与切换成本别被“兼容MySQL”四个字迷惑RDS MySQL和PolarDB MySQL都宣称兼容MySQL但“兼容”不等于“完全一样”。RDS MySQL本质就是官方MySQL的托管形态兼容度接近100%从自建MySQL迁过来改动极小。PolarDB MySQL版在语法层面同样高度兼容但底层架构决定了它有一些独有参数和限制比如部分插件可能不支持、某些参数调整方式不同、部分高级特性向云原生架构倾斜。所以我的建议很明确存量老系统优先考虑RDS MySQL求稳新项目、大数据量、高并发场景再考虑PolarDB。顺序反了容易在迁移阶段踩坑。3. 场景化选型推荐矩阵你的业务放在哪个格子里3.1 初创项目、个人学习、低并发业务怎么选这类业务的特点是数据量小、并发低、生命周期不确定甚至可能做着做着就换方向了。我的推荐是直接用云数据库的基础版或者干脆先用一台低配ECS自建MySQL做开发测试。很多开发者习惯本地电脑装MySQL写代码这是完全没问题的推荐用官方安装包或者Docker快速起一个实例重点把SQL基本功练扎实。到了需要部署到公网演示或给少量用户试用时直接开一个RDS MySQL基础版单节点架构价格便宜能跑正式业务又不用自己管备份和监控性价比极高。这里我不建议新项目一上来就上复杂架构。数据量还没起来时就考虑读写分离、分库分表属于过度设计。先把业务跑通等用户量明确增长之后再考虑架构升级完全来得及。3.2 存量业务系统上云平稳迁移比什么都重要如果你已经有一套自建MySQL跑了好几年里面存着订单、用户、财务这类核心数据那第一优先级就是平稳而不是炫技。这种场景我强烈推荐RDS MySQL高可用版或集群版。原因很直接业务代码里可能有大量SQL是十年前写的甚至有些用了存储过程、触发器、自定义函数。RDS MySQL对这类“老代码”的兼容性最好迁移过去基本不用改应用。选型时重点看容灾能力高可用版默认一主一备跨可用区部署可以扛住机房级别的故障。迁移过程中我建议用官方数据传输工具DTS做不停服迁移源库业务正常读写的情况下完成全量加增量同步最后选择一个业务低峰期做切换再把流量切到RDS上。整个过程对终端用户几乎无感知。不要自己用mysqldump导出再导入十几G数据量还能勉强接受上百G就非常痛苦而且迁移期间业务不能停根本没法操作。3.3 高并发互联网、电商大促场景怎么选这类业务有两个明显特征流量波峰波谷差距大大促时流量可能是平时的十倍甚至几十倍数据量增长快订单、日志、用户行为数据几个月就能攒到几个TB。我的推荐是PolarDB MySQL版。首先是弹性扩展能力大促前提前加两个只读节点把读流量分摊出去大促结束再释放成本可控其次是单库容量大不用过早面对分库分表最后是物理复制延迟低读写分离后业务不会因为主从延迟读到旧数据。举个我实际经历过的场景某电商类客户活动期间读写比到了10比1以上单库QPS峰值好几万。之前自建MySQL扛不住只能砍降级逻辑迁移到PolarDB后加了两个只读节点CPU使用率从90%多降到了40%左右慢查询也明显减少。这种场景下自建方案不是不行而是你需要在硬件、架构、运维上投入巨大成本才能达到同样的效果。3.4 成本敏感、容灾要求一般的业务怎么妥协不是所有业务都不能容忍一秒钟的中断。做数据分析的内部系统、定时跑批任务的后台、Demo演示项目这类业务的核心诉求就一个字省。RDS MySQL基础版就是为这个场景准备的单节点实例没有备库价格比高可用版便宜不少数据备份也是自动做的真出了问题可以把实例恢复到创建后的某个时间点。搭配包年包月或者资源包成本能压到很低。我自己给一些中小企业做方案时会建议他们把“核心生产库”和“非核心业务库”分开部署核心交易走高可用版或PolarDB非核心系统统一放基础版。很多成本焦虑来自“所有库都用同一个规格”稍微分一下层费用就能降下来一大截。3.5 推荐矩阵总表一张图对号入座业务场景首选方案备选方案选型逻辑个人学习 / 本地开发本地Docker MySQLRDS MySQL基础版成本优先练手为主初创项目 / 低并发SaaSRDS MySQL基础版自建MySQL单机低成本起步规范运维存量系统上云 / 传统企业核心库RDS MySQL高可用版RDS MySQL集群版兼容性优先平稳迁移高并发互联网 / 电商大促PolarDB MySQL版RDS MySQL集群版读写分离弹性扩展扛峰值流量海量数据存储 / 百TB级业务PolarDB MySQL版自建分库分表拒绝过早分片横向扩展成本敏感 / 非核心后台RDS MySQL基础版自建低配ECSMySQL省钱是第一要务这张矩阵只是一个起点。真正的选型还要结合团队的技术储备和业务的增长预期来判断不要只看今天的压力也要想想半年后可能面对的新场景。4. 从自建迁移到云数据库的实际操作要点4.1 别再用mysqldump硬扛DTS全量增量才是正解很多第一次上云的朋友习惯性执行mysqldump把数据导成SQL文件再导入云数据库。这个方案在数据量小、业务可以停的时候没问题但线上核心库完全不能这么干。DTS数据传输服务的做法是先做一次全量数据迁移把当前数据导入目标库然后通过解析源库的binlog持续同步增量数据。这样源库全程不停服迁移期间业务照常读写最后切换时只需要把应用连接串改到云数据库停写时间只有分钟级甚至秒级。迁移前要梳理清楚的对象包括所有库表结构、账号和权限、存储过程、触发器、事件调度器、外键约束。MySQL的存储过程和触发器有时会成为迁移的隐藏雷区DTS能同步大部分但如果你用的版本比较老某些语法到新环境可能会报错。稳妥的做法是先做一次全量迁移到测试实例把存储过程、触发器手动检查一遍再跑应用的核心接口做回归。4.2 连接方式改造与应用适配自建MySQL时代大家习惯直接用IP加端口连数据库。云数据库默认都在VPC内网里连接地址一般是一个高可用的域名后面绑定了主备节点。应用层要把原来的IP连接改成域名连接别再用IP硬编码。如果你的应用使用了数据库连接池像HikariCP、Druid记得重新评估连接池大小。云数据库默认有最大连接数限制规格越高连接数上限越大。很多时候应用报“too many connections”不是数据库出故障了而是连接池配置过大、应用没有及时归还连接。我一般建议HikariCP的maximumPoolSize控制在20到50之间对绝大多数业务已经足够。另外要考虑的是SQL语法和参数兼容性。RDS MySQL和PolarDB对标准SQL的兼容性都很好但一些细节需要留意例如sql_mode设置可能不同某些日期处理行为可能有差异字符集也建议在迁移前统一为utf8mb4。这些差异在数据量小的时候看不出问题等数据跑起来再想改代价就大了。4.3 参数与性能调优的几个关键点云数据库默认参数通常偏保守目的是保证任何业务都能稳定运行。但你的业务完全可以把一些参数调得更激进。连接数上限如果确认业务需要更多连接可以在控制台调整max_connections。innodb_buffer_pool_size这是InnoDB最重要的内存参数决定缓存多少数据和索引。云数据库默认值一般按实例规格的百分比设置如果内存有富余可以适当调高能明显降低磁盘IO。慢查询阈值默认慢查询阈值可能比较大建议调到1秒甚至更低配合云数据库的慢查询日志和性能洞察能快速定位问题SQL。自动提交和事务隔离级别保持默认即可除非你对业务特性非常清楚。我见过太多人上云之后什么都不调等于花了高配的钱用着低配的性能。至少要把慢查询日志打开、把常见监控项配好告警这样后面出问题才有据可查。5. 常见问题与避坑实录5.1 连接数爆满不一定是数据库不够强现象很典型业务高峰时应用大量报错提示获取数据库连接失败或者连接数超限。很多人第一反应是扩容但扩完之后过几天又出现同样的问题。这时候先别急着加钱去数据库控制台看看当前活跃连接数、连接来源分布再到应用侧检查连接池配置。最常踩的坑是连接池的maximumPoolSize设得太大比如一个应用起了4个实例每个实例连接池100加起来就有400个连接数据库上限才200不爆才怪。合理做法是把连接池控制在必要范围同时清理掉那些忘记关闭连接的历史代码。如果并发实在太高再考虑加数据库规格或者前面加一层数据库代理Proxy让连接复用起来。5.2 主从延迟只读节点上的“历史数据”问题PolarDB和RDS做读写分离之后最常遇到的现象是刚写入的数据走只读节点查询时查不到。这就是主从延迟。传统主从的延迟来源主要是大事务和慢SQL主库执行了一个两三分钟的大事务从库要等它跑完才能应用或者从库本身在跑一个复杂查询把复制线程堵住了。逻辑复制还会放大延迟因为主库的每条更改操作都要在从库重新执行一遍。PolarDB的物理复制机制在这块有先天优势延迟通常能控制在毫秒级到秒级。如果延迟仍然明显优先排查是否有大事务、delete/update是否没有走索引导致锁了大量行。业务侧也可以做优化对实时性要求极高的读操作强制走主库读多写少且允许一定延迟的统计查询再走只读节点。5.3 备份与恢复别等出事才后悔自建MySQL时代备份经常是“写了脚本就算有”但从不验证备份能不能恢复。我见过最典型的翻车现场服务器磁盘坏了拉出上周的备份文件发现备份文件大小不对因为脚本执行时MySQL正在写数据导出文件本身不完整恢复直接失败。云数据库的自动备份基本解决了“没有备份”的问题RDS和PolarDB都支持按时间点恢复配合binlog可以把数据恢复到秒级。但我要强调一句自动备份不等于自动演练过建议每季度做一次恢复测试在测试实例上把备份还原出来跑一遍核心接口确认数据完整可用。这个动作不复杂却能让你在真正出故障时不慌。5.4 费用超预算都是规格和存储“堆”出来的云数据库用着舒服但费用也是一笔一个脚印。很多人月底看账单才发现超支主要原因是实例规格开得高、只读节点常年挂着、备份存储空间越积越多、按量付费没转包年包月。建议每两个月做一次成本审视CPU使用率长期不到10%的实例大胆降配只读节点只在业务高峰期才需要平时释放掉备份集保留周期调成合理范围历史备份按需下载后删除长期运行的实例尽量转包年包月再叠加存储资源包。数据库费用不是一个死数它是可以主动管理的。最后说点个人体会。选型这件事真的不是非黑即白更不是一句话能定死。我更愿意把决策拆成“业务阶段”来看新项目从第一天开始就上PolarDB大概率不用后悔老系统迁移先走RDS跑通业务再根据演进需求决定要不要切到PolarDB。我自己的习惯是无论选哪条路都先把备份恢复方案确认好再把连接池、慢查询、告警这些基础项配齐。这些地基不打好再牛的数据库架构也会在某个凌晨给你颜色看。