1. 从“能用”到“好用”：先想清楚为什么要纠结选型
做数据库选型这件事，我见过太多人上来就问“自建 MySQL 和 RDS 到底哪个好”，然后吵得不可开交。实际上这是个伪命题，答案完全取决于你自己的处境：你的团队有没有专职 DBA，你的业务流量曲线是平稳还是脉冲式，你对数据库的运维容忍度有多高，甚至你的预算结构是喜欢一次性投入还是喜欢按月付费。
我在阿里云上摸爬滚打这些年，既帮朋友从零搭过自建 MySQL 主从，也接手过从 ECS 自建迁到瑶池数据库 RDS 的案例，还干过把 RDS 迁回自建的“逆行”操作。每次都有人问：你折腾这些图啥？我的回答是：数据库选型不是选一个“最好的”，而是选一个“出错成本最低、后续维护最省心、和你的团队能力最匹配”的方案。
这篇文章不是要告诉你“RDS 吊打自建”或者“自建才是王道”，而是把两边最真实的优劣、成本构成、坑点、迁移路径全部摊开讲透。你会看到参数对比、计算公式、实操步骤、我踩过的坑，以及那些云厂商文档里不会写清楚的细节。文章面向的人群很明确：中小团队的技术负责人、独自扛项目的全栈开发者、以及那些正在从自建转向托管数据库、或者准备从托管迁回自建的运维同学。
先说一个我反复强调的观点：如果只是做个个人博客、内部工具、日活几百的 Demo，自建 MySQL 完全够用，甚至更自由。但如果是涉及真金白银的交易系统、需要保证 SLA 的业务、或者团队里没人愿意半夜爬起来处理主从延迟，瑶池数据库 RDS 的价值就体现出来了。选型本质上是在“控制成本”和“转移风险”之间找平衡点。
2. 两种方案的核心差异：你要管的到底还剩多少
2.1 自建 MySQL：全部掌控，也全部负责
自建 MySQL 最常见的形态是在阿里云 ECS 上用云盘或本地盘跑一个独立部署的 MySQL 实例，自己负责操作系统、MySQL 安装、配置优化、备份恢复、高可用、监控告警、安全加固、版本升级。它有一个隐藏前提：你得有“能扛事”的人。不是说团队里要有一个专职 DBA，但至少要有一个人能在凌晨两点被电话叫醒后，冷静地执行一条mysql命令行去处理锁等待或主从故障。
从技术上讲，自建 MySQL 的优势是“没有中间层”，SQL 执行路径短，参数完全可控。innodb_buffer_pool_size、sync_binlog、innodb_flush_log_at_trx_commit这些关键参数都是你想怎么调就怎么调。RDS 虽然也能改一部分参数，但有些内核级配置是不开放的，比如某些情况下performance_schema的完整状态、部分插件加载。对于追求极致性能或特殊业务场景（比如需要自定义 UDF、特殊复制架构）的团队来说，自建可能反而是唯一选择。
但自建的风险同样明显：你得自己处理数据安全、补丁漏洞、磁盘扩容、跨可用区容灾这些问题。我曾经见过一个团队把 MySQL 装在系统盘上，跑了两年没出问题，结果某天系统盘 IO 被打满，数据库直接卡死，最后不得不停机迁移。这类事故在自建场景里太常见了，因为很多人刚部署的时候根本不会考虑磁盘规划。
2.2 瑶池数据库 RDS：把运维复杂度打包交给云厂商
瑶池数据库 RDS 是阿里云的托管关系型数据库服务，底层也是 MySQL 内核，但它在自建 MySQL 之上做了大量产品化封装：自动化运维、高可用切换、备份恢复、监控告警、参数模板、性能洞察、SQL 审计等功能开箱即用。你不需要关心 MySQL 装在哪台 ECS 上、数据文件落在哪个目录、binlog 是否被清理——这些都属于“平台责任”。
选 RDS 最核心的理由是“降低故障半径”。云厂商的承诺 SLA 和你团队自己搞的高可用完全是两码事。自己搭主从，即使做了半同步复制，也很难保证切换后数据零丢失；而 RDS 高可用版默认提供主备架构，切换动作由控制台和后台 Agent 协调完成，正常情况下业务侧只会感知到连接闪断，重启一下应用就好。这种能力对大多数中小团队来说，单靠自己做不现实，或者做出来也远没有 RDS 稳定。
当然，RDS 也有它的“烦恼”：不能 SSH 登录底层机器，不能随便改配置文件，某些高级特性（比如全文索引插件、部分审计策略）需要额外开通或受版本限制。如果你习惯直接编辑my.cnf重启实例，那 RDS 会让你觉得束手束脚。另外，RDS 的定价策略比较复杂，需要按规格、存储、备份空间、公网流量、只读实例等多个维度计费，如果设计不合理，账单可能比你想象的高不少。
2.3 一张表看明白两者的职责边界
我整理了一个对比维度，可以直接用来评估“该谁干活”。
| 对比维度 | 自建 MySQL（ECS 部署） | 瑶池数据库 RDS |
|---|---|---|
| 安装部署 | 自己下载安装包、初始化、配置 | 控制台点几下，自动创建 |
| 高可用 | 自建主从/MMM/MHA/Orchestrator，自己维护 | 高可用版自动主备切换 |
| 备份恢复 | 自己写备份脚本，定期验证恢复 | 自动备份，支持任意时间点恢复 |
| 监控告警 | 自建 Prometheus + mysqld_exporter 等 | 自带监控，告警规则丰富 |
| 内核优化 | 完全可控，可自定义插件 | 只能改白名单内部分参数 |
| 成本结构 | 主要为 ECS 磁盘带宽费用，MySQL 本身免费 | 按实例规格+存储+备份+流量综合计费 |
| 故障处理 | 自己排查，自己修复 | 提工单，部分高危操作由 DBA 协助处理 |
| 安全加固 | 自己处理防火墙、SSL、最小权限 | 默认有白名单、SSL、透明数据加密等选项 |
| 适合场景 | 学习、测试、内部系统、对成本极其敏感 | 核心业务、要求 SLA、人手不足 |
这个表不是绝对标准，但它能帮你快速定位自己的“舒适区”。如果你看到表中的“高可用、备份恢复、监控告警”这些词就觉得头疼，那 RDS 几乎肯定更适合你；如果你看到 RDS 的“参数不可控、内核封闭”就浑身难受，那自建 MySQL 可能才是你的菜。
3. 成本账怎么算：别只看首月账单，要看三年总拥有成本
3.1 自建 MySQL 的单台费用拆解
先以一台阿里云 ECS 跑单机 MySQL 为例。以我常用的配置估算：2核4G ECS，40G ESSD 云盘，按量或包年包月按优惠价年付大约 1000 元出头。如果再买一台同样配置的 ECS 做从库，再加一台低成本 ECS 做监控跳板，那光计算资源一年就要 2500 到 3000 元。
但这只是起步。你还需要公网带宽（如果业务要对外提供 API，哪怕 1Mbps 也会按固定带宽计费，单台加几十元一月）、云盘快照空间（备份占用）、OSS（如果要把备份归档到对象存储）、SLB（如果要做多节点负载均衡）。把这些杂项全部算上，一个“看起来只有两台 ECS”的自建 MySQL 集群，一年成本通常在 5000 元左右，这还只是为了把基础架构搭起来。
不要忘了隐性人力成本。自建 MySQL 的每次大版本升级、安全补丁修复、磁盘水位优化、慢查询分析，都需要有人花时间来处理。按一个中级运维工程师时薪 150 元、每次维护平均耗时 3 小时来算，一年 10 次维护就是 4500 元。很多时候这笔钱都是沉默成本，没人会记进报表里，但它真真切切存在。
3.2 RDS 的费用构成与规格选择
瑶池数据库 RDS MySQL 的计费主要是三块：实例规格（CPU和内存）、存储空间、备份空间。按相同 2核4G 规格、40G ESSD 云盘存储来估算，包年包月大约每月 800 到 1000 元，一年就是 1 万元上下。听起来比自建贵不少，但这已经包含了高可用主备（一般高可用版规格至少需要 2核4G，如果选择双节点规格，价格会更高）、自动备份、监控告警、一键 version 升级等能力。
规格选择是 RDS 省钱的关键点。经常有人一上来就选最大的规格，怕以后扩容麻烦。实际上 RDS 支持在线升级规格，业务低峰期调整基本无感。我的建议是：初期按“日常峰值 CPU 不超过 60%、内存不超过 70%”来选，留一定余量即可，不要贪大。如果你有读写分离需求，可以后期再加只读实例，用完再释放，按量付费的只读实例在临时场景下非常划算。
备份空间是另一个容易被忽视的费用点。RDS 默认保留 7 天备份，如果你开启了“秒级备份”或增加日志备份频率，备份空间费用会明显上涨。自建 MySQL 如果只保留本地备份，这部分费用可能为 0，但安全性和恢复能力也会相应下降。所以成本对比要放到“同等能力”前提下，否则没有意义。
3.3 三年总拥有成本对比
我按一个“生产可用、高可用、可恢复”的标准模型来对比三年成本。自建方案取两台 ECS（主从）+ 一台监控机 + 公网带宽 + 备份归档到 OSS + 每年 10 次人工运维；RDS 方案取高可用版 2核4G + 40G ESSD + 7 天备份空间，并按年付计算。
| 成本项 | 自建 MySQL（3年） | 瑶池数据库 RDS（3年） |
|---|---|---|
| 计算资源 | 3台 ECS 约 9000 元 | 实例规格约 30000 元 |
| 存储/备份 | 云盘+快照+OSS 约 2000 元 | 存储+备份空间约 4000 元 |
| 网络带宽 | 固定带宽约 3000 元 | 内网免费，公网流量另计约 2000 元 |
| 人工运维 | 30次维护约 13500 元 | 几乎为 0，部分操作提工单 |
| 合计估算 | 约 27500 元 | 约 36000 元 |
这个对比里，自建 MySQL 三年成本大约低 8500 元，但前提是你有一个能处理所有故障的运维人员。如果把这个人的有效工作时间换算成业务开发时间，自建方案节省的 8500 元可能还不够抵两次故障排查的工时可贵。所以我的建议是：如果你的项目生命周期超过一年、且未来有扩展可能性，不要太纠结那几千块差价，RDS 的高可用和自动运维在关键时刻能救你一命。
4. 自建 MySQL 实操记录：从零搭建到基础调优
4.1 在阿里云 ECS 上部署 MySQL 8.0
如果你已经决定要自建，我建议直接上 MySQL 8.0，别再用 5.7 了。8.0 在性能、安全性（默认 caching_sha2_password 认证插件）、窗口函数、CTE 等方面都有明显提升，而且阿里云官方提供的 MySQL 源也已经同步到 8.0 系列。
部署过程其实很固定。我习惯先用 yum 或 apt 把基础工具装好，然后添加官方 MySQL Yum 源或直接下载 RPM 包安装。这里有个小细节：阿里云 ECS 通常已经有 yum 源，你只需要下载mysql80-community-release-el7（如果是 CentOS 7）或mysql80-community-release-el9（如果是 Alibaba Cloud Linux 3）安装即可。装完后执行mysqld --initialize，初始化过程会生成一个临时 root 密码，日志会打印在/var/log/mysqld.log里。
初始化后第一件事就是把 root 密码改掉，然后创建业务账号。我见过太多人用 root 账号跑业务，这是极其危险的做法。哪怕只是在测试环境，也应该遵循“最小权限”原则：业务账号只拥有对应库表的增删改查权限，运维账号才有 DDL 权限。权限拆分做得好，即使应用被注入，攻击者也无法轻易拿到整个数据库的控制权。
4.2 关键参数调优：不要盲目照搬网上的配置
自建 MySQL 最大的优势是参数可调，但最大的坑也是参数可调。很多人喜欢从网上复制一段“高性能 MySQL 配置”，然后直接粘贴到my.cnf，结果跑起来性能反而更差。原因很简单，这些配置往往来自高配服务器，比如innodb_buffer_pool_size = 128G这种，放到 2G 内存的 ECS 上连启动都可能失败。
我推荐一套保守但适用的初始参数模板，你可以在此基础上小步调整：
[mysqld] port=3306 datadir=/data/mysql socket=/var/run/mysqld/mysqld.sock pid-file=/var/run/mysqld/mysqld.pid character-set-server=utf8mb4 collation-server=utf8mb4_0900_ai_ci default-storage-engine=InnoDB # 缓冲池设为物理内存的 50%-70% innodb_buffer_pool_size=1G # 日志文件总大小合理设置，保证崩溃恢复速度 innodb_log_file_size=256M innodb_flush_log_at_trx_commit=1 sync_binlog=1 # 连接数不必盲目加大 max_connections=500 # 关闭反向解析，减少连接耗时 skip-name-resolve # 慢查询日志 slow_query_log=1 slow_query_log_file=/var/log/mysql-slow.log long_query_time=2这里特别说明一下innodb_flush_log_at_trx_commit=1和sync_binlog=1。这两个参数是一致性和性能之间的博弈：都设为 1 时，每次事务提交都要强制刷盘，性能损耗较大，但数据安全性和崩溃恢复能力最强。如果业务对吞吐量极其敏感，且能接受最多丢失最后 1 秒左右的事务，可以调整为innodb_flush_log_at_trx_commit=2。但我不建议在核心交易场景下降低这个参数。
4.3 自建 MySQL 的主从复制与高可用
生产环境自建 MySQL 至少要搭一主一从。以前主流方案是 MHA，配置复杂，切换脚本维护成本高；现在更多团队用 MGR（MySQL Group Replication）或 Orchestrator。MGR 在 MySQL 8.0 中已经相对成熟，单主模式可以自动选主，但配置过程涉及网络互信、事务一致性检查，对中小团队来说上手门槛不低。
如果只是想做一个“能自动切换”的主从环境，最简单的方案是使用mha4mysql-node+mha4mysql-manager或直接用 Orchestrator 来做探测和故障转移。我个人更喜欢 Orchestrator，它支持 HTTP API、可视化界面和基于 Raft 的自身高可用，比 MHA 更容易维护。你只要把 MySQL 实例的 IP、端口、复制账号填进去，它能自动发现主从拓扑并处理切换。
但请注意：主从复制不等于高可用。复制链路上的任何中断、主库磁盘满、从库 relay log 损坏，都会让复制停止。你需要配套一个监控器，定期检查Seconds_Behind_Master和复制线程状态，一旦发现异常，立即告警并尝试修复。没有监控的主从，就是个定时炸弹。
5. 瑶池数据库 RDS 控制台操作全流程
5.1 创建实例时最容易忽略的选项
如果决定用 RDS，创建实例的流程并不复杂，但有几个选项需要特别留意。
第一是“数据库引擎版本”：MySQL 8.0 是目前的主流选择，如果代码里用了老协议或者依赖某些老库驱动，8.0 的默认认证插件可能会导致连接失败。解决办法是在 RDS 控制台的“参数设置”里把default_authentication_plugin改为mysql_native_password，或者升级客户端驱动。提前确认这步，可以避免上线当晚被连接错误折磨。
第二是“实例架构”：基础版只有单节点，价格便宜，但不提供 SLA 保障，只适合测试；高可用版有主备双节点，故障自动切换，生产环境必须选它；集群版支持多节点和读写分离，费用更高。我建议核心业务从高可用版起步，后续需要扩展再升级，而不是一开始就选集群版。
第三是“存储类型”：ESSD PL1 已经能满足绝大多数场景，PL2/PL3 适合 IO 非常高的大项目。存储空间设置以后只能扩容不能缩容，所以你可以按未来 1 年 50% 增长量来预估，但也不要一次性买很多，RDS 扩容很方便，磁盘空间不足时会有告警，你在控制台一键扩容即可。
5.2 白名单、账号权限与连接串配置
RDS 创建完成后，第一步是设置 IP 白名单。阿里云 RDS 的白名单逻辑是：不在白名单内的 IP 一概不能连接。如果你用 ECS 连接 RDS，建议把 ECS 的内网 IP 加入白名单，而不是按公网 IP 方式连接。两个产品在同一个 VPC 下，内网连接延迟低、免费、更安全。
账号方面，RDS 控制台创建的高权限账号默认拥有所有权限，业务账号按需授权。我通常会创建两个账号：一个是高权限账号（只用于运维管理），一个是业务账号（只对应用库有 SELECT、INSERT、UPDATE、DELETE 权限）。如果你要做数据导入导出，可以用 DMS（数据管理服务）登录，也可以使用本地客户端。不要为了图省事让业务代码连高权限账号。
连接串配置上，有一点容易被忽略：RDS 的连接串里一般包含“端口”和“数据库名”，但不会帮你设置“连接超时”和“读超时”。在 Java 的 JDBC 里，我建议显式加上connectTimeout=3000&socketTimeout=30000&autoReconnect=true，这样可以避免数据库发生主备切换时，应用因为连接池里的旧连接等待超时导致大面积报错。这个细节在自建 MySQL 里同样适用。
5.3 备份恢复与“任意时间点恢复”的正确使用姿势
RDS 的自动备份默认是每天一次，备份文件在“备份恢复”页签里可以查看和下载。很多人只用过手动全量备份，忽略了“任意时间点恢复”功能。这个功能基于 binlog 实现，可以让你把实例恢复到过去 7 天内的任意一秒，在应对误删数据、错误 UPDATE 时非常有用。
实操时正确的姿势是：先通过控制台发起“克隆实例”或“按时间点恢复”，选择目标时间点，等待新实例创建完成，然后在新实例中确认数据是否恢复正常，确认后再把业务切换到新实例或从新实例导出所需数据。这个过程一定要演练至少一次。我见过太多团队直到事故发生时才发现自己没有权限操作恢复、恢复出来的库表数据不对、或者恢复时间长达数小时。预先演练就是给未来事故上保险。
另外，RDS 的 binlog 文件也可以下载。如果你希望把 RDS 数据同步到自建 MySQL 或者其他环境，可以在“备份恢复”里下载 binlog，然后用mysqlbinlog工具还原增量数据。不过这个过程对 binlog 格式和位点要求较高，操作前务必在测试环境验证。
6. 在线迁移与切换：自建和 RDS 之间双向移动的实操经验
6.1 从自建 MySQL 迁到 RDS：最平滑的方式是什么
把自建 MySQL 迁到 RDS，最靠谱的方式不是“先全量导出再导入”，而是用 DTS（数据传输服务）。DTS 支持实时增量同步，可以做到业务几乎无感迁移。迁移前需要在自建 MySQL 上开启 binlog，并确保 binlog 格式为 ROW，同时修改保留时长，让 DTS 有足够时间追平增量。
DTS 迁移任务一般有三个阶段：结构迁移、全量迁移、增量迁移。结构迁移会把表结构、函数、存储过程等对象迁移过去；全量迁移会搬数据；增量迁移会持续同步源库产生的新数据。等到源库和目标库数据延迟小于几秒时，你可以在业务低峰期进行“业务切换”：停写操作，等延迟追平，然后把应用连接切换到 RDS，再启动业务。
这里有一个非常重要的坑：在 DTS 全量迁移时，如果源库有大表且磁盘读写能力弱，迁移任务可能会对源库造成明显的 IO 压力，影响线上业务。我建议在业务低峰期启动 DTS 任务，或者先给源库加一个只读从库，让 DTS 从从库读取数据。另外，迁移前一定要梳理清楚“源库账号”的权限，DTS 需要源库的REPLICATION SLAVE、REPLICATION CLIENT等复制权限。
6.2 从 RDS 迁回自建 MySQL：大部分人不会告诉你注意什么
有些场景下需要把 RDS 迁回自建：成本控制、合规要求、或者你需要完全控制数据库内核。这个过程比自建迁 RDS 要麻烦一点，因为 RDS 不会直接给你底层文件，你需要通过逻辑导出或 DTS 反向同步。
我最常用的是逻辑备份：用mysqldump在 RDS 上导出全部数据，然后在自建 MySQL 上导入。这个方案简单可靠，但要注意：RDS 的mysqldump需要设置--single-transaction避免锁表；导出大库时建议加上--set-gtid-purged=OFF，否则导入到非 GTID 实例会报错。
如果希望尽量减少停机时间，可以使用 DTS 的“从 RDS 到自建 MySQL”的同步任务。DTS 同样支持反向同步，先在自建环境建好空库，然后 DTS 做全量+增量同步，最后切换。但反向同步有一个注意点：RDS 的某些系统库/参数和社区版不同，比如性能洞察、SQL 洞察等依赖的审计表，在自建库上并不存在，因此 DTS 只同步用户自建库表，不要盲目全实例同步，否则会报错。
无论往哪个方向迁移，迁移后都要做三轮验证：第一轮验证表数量和行数是否一致，第二轮抽查关键业务的写入和读取是否正常，第三轮在业务低峰期模拟故障切换，确认应用能自动重连到新库。只有这三轮全部通过，才算迁移成功。
7. 常见问题与踩坑实录：这些问题你迟早会遇上
7.1 SQL 连接报错与认证插件不匹配
很多人在从 MySQL 5.7 自建迁到 RDS MySQL 8.0，或者反过来的时候，会遇到类似Authentication plugin 'caching_sha2_password' cannot be loaded的报错。原因就是客户端驱动版本太老，不支持 MySQL 8.0 的默认加密方式。解决这个问题通常有三种办法：升级客户端驱动到支持 caching_sha2_password 的版本；修改 RDS 或自建库的默认认证插件为 mysql_native_password；或者在创建用户时显式指定IDENTIFIED WITH mysql_native_password BY 'xxx'。
我建议优先升级驱动，因为 mysql_native_password 在 MySQL 8.0 中已经标记为废弃，未来版本可能会移除。如果业务系统由第三方维护无法升级驱动，再考虑修改认证插件。但这个修改涉及到所有新创建用户，改动面较大，要提前在测试环境验证。
7.2 主从延迟导致读写分离数据不一致
无论自建还是 RDS 只读实例，主从延迟都是一个绕不开的话题。RDS 控制台的只读实例延迟监控通常显示为“秒级”，但这只能说明平均情况。如果业务有“写后立即读”的强一致需求，比如用户下单后马上要看到订单详情，而查询走了延迟很高的只读节点，就很容易出现“明明写入成功但查不到”的诡异问题。
解决思路有三种：关键读操作强制走主库，通过设置事务只读标记或者读写分离中间件规则，把特定 SQL 路由到主库；业务层根据数据延迟容忍度，对刚写入的 key 做短时间缓存；对于无法忍受延迟的场景，放弃只读实例，直接主库承担读压力。这三种方案没有绝对的对错，关键是根据业务形态取舍。
我在实际项目中遇到过一种更隐蔽的情况：大事务造成主库 binlog 积压，从库回放跟不上，导致从库延迟长达几十分钟。排查方法很简单，登录 RDS 控制台或自建从库执行SHOW SLAVE STATUS\G，观察Seconds_Behind_Master和Exec_Master_Log_Pos。如果是大事务导致，需要优化业务逻辑，把大批量 UPDATE/DELETE 拆成小批次提交，同时适当增大从库的slave_parallel_workers提升并行复制能力。
7.3 磁盘空间突增与 binlog 无限膨胀
自建 MySQL 最常见的磁盘故障是 binlog 没有及时清理。默认情况下 binlog 的过期时间expire_logs_days在 MySQL 5.7 中是 0，表示需要手动清理或依赖日志清理机制；MySQL 8.0 中则是binlog_expire_logs_seconds为 2592000（30天）。30 天其实挺长的，如果业务写入量大，binlog 会占很大的磁盘空间。
建议把自建库的 binlog 保留时间缩短到 7 天左右，同时配合云盘监控告警，当磁盘使用率超过 75% 时提醒你处理。RDS 的话你可以在控制台调整“备份设置”里的日志备份保留时间，并注意观察“实例使用量”里的日志空间大小。
另外，RDS 的“回收站”和“临时文件”也可能导致空间暴涨。最常见的是大量排序或大事务产生的临时表写到了临时目录，如果临时目录空间不够，SQL 会直接报错。自建环境可以在my.cnf中调整tmpdir指向独立的大分区；RDS 无法直接改这个路径，但你可以通过优化 SQL 减少临时表的使用，比如避免SELECT *加ORDER BY的大结果集排序。
7.4 备份恢复出来的数据“不对”：最常见的三个原因
备份恢复后数据不对，通常不是备份功能坏了，而是操作姿势不对。第一，恢复时选错了时间点，尤其是跨时区的场景。控制台时间默认是本地时间，如果你用 UTC 时间判断“恢复到现在”，很可能差 8 小时。第二，误用全量备份恢复后没有应用 binlog，导致数据回到备份时刻，而不是你期望的“故障前的状态”。第三，没有关闭目标实例上的外部写入，恢复过程中业务还在写，导致数据状态混乱。
正确的恢复流程是：先创建一个临时实例，在临时实例中恢复，然后通过只读账号验证数据，确认无误后再把流量切到临时实例或导回到生产实例。在整个操作过程中，生产实例最好保持只读或停止写入。别图省事直接在源实例上执行恢复，否则一旦恢复失败，源数据也会被覆盖，那才是真正的灾难。
8. 一些来自实操的选型建议
做选型决策时，我一般会把以下三个问题写在纸上，答案会直接指向最终方案。
第一，团队里有没有“数据库负责人”？不是写 SQL 的研发，而是能处理备份恢复、主从复制、性能分析、故障切换的人。如果没有，那就别犹豫，选 RDS。第二，业务对数据库 SLA 的真实要求是什么？如果业务允许宕机半小时以上，自建完全能接受；如果要求“出问题 5 分钟内恢复”，自建的高可用投入会非常大，RDS 的主备切换优势显而易见。第三，未来 12 个月数据库的预期规模是多少？如果数据量和访问量都会快速增长，RDS 的弹性扩容能让你少操心很多事；如果业务稳定，数据量不大，自建就足够了。
我个人在实际使用中的感受是：中小团队在云上做业务，最稀缺的资源不是服务器，而是运维精力和半夜的好睡眠。如果数据库故障让你提心吊胆，那多花的预算买的就是“睡得安稳”。反过来，如果你正好是喜欢研究数据库内核、愿意深挖源码和参数细节的人，自建 MySQL 带给你的成长价值是任何托管服务都给不了的。
最后再分享一个小技巧：无论你最终选择自建还是 RDS，都建议把数据库的参数、账号权限、备份策略、恢复演练记录写进团队 Wiki。数据库选型只是一个开始，后续的日常运营、故障复盘、容量规划才是持久战。把这些规范沉淀下来，即使核心人员变动，数据库这块也能平稳交接，不会因为一个人走了就变成无人敢碰的黑匣子。
