2.1 自建 MySQL 还是云数据库：算完账我选了后者

社区上线第二个月，某天凌晨两点我收到告警：磁盘 IO 打满。爬起来一看，MySQL 正对一张图片元数据表做临时表排序，临时表落盘把整机 IO 拖垮，跑在同一台 CVM 上的 Python 业务也跟着大面积超时。重启服务、杀慢查询、清临时表，折腾到凌晨四点才完全恢复，第二天整个人都是飘的。

那天我意识到一个问题：数据库和应用挤在同一台机器上，CPU、内存、IO 三样资源互相抢，应用高峰就是数据库高峰，反过来也一样，迟早要再出事。真正稳妥的做法是把数据库拆出去独立部署——哪怕先只拆到同一地域的另一台机器上，也是质的改善。摆在面前的路有两条——再买一台 CVM 自建主从 MySQL，或者直接买云数据库 MySQL。我花了一个下午算账，最后选了后者。这篇把算账过程完整写出来，给同样在纠结的人一个参考。

先把太长不看的结论放这儿：如果只是想把产品稳稳上线、没有专职运维，云数据库几乎在每一个维度上都更适合；只有当你把数据库本身当作核心竞争力、或者有特殊合规要求时，自建才值得认真考虑。下面逐项展开。

上一篇把应用搬上了 CVM，这一篇来解决它的数据存储问题。数据库该怎么放，是每个上云的人绕不过去的选择题。

一、先问自己：我到底有没有时间运维

在算钱之前，我先算了一笔时间账。独立开发者的处境很现实：白天有本职工作，晚上和周末才有空写代码，这几个小时要是花在装数据库、配主从、写备份脚本、半夜处理故障上，产品永远做不完。云服务器我已经在用，远程登录就能管理，而数据库的运维复杂度比 Web 应用只高不低——它对参数、权限、备份容错的要求都更高，每一个都是可以单独出书的领域。

所以真正的选择题不是哪个更便宜，而是：我的时间花在哪一段收益最大。对当时的我来说，答案很清楚：写业务功能、拉新留存，而不是给 MySQL 当兼职 DBA。想通这一点，后面的账就好算了。另一个隐性收益是心态：数据库出问题时，自建方案里你只能指望自己；用云数据库，至少还有厂商的技术支持和工单可以托底，半夜惊醒的次数会明显变少。我见过太多独立项目死在运维拖垮热情上，而不是死在没有市场上，这是一件想想都可惜的事。

二、自建 MySQL 要干的活

先列清单。在一台全新 CVM 上自建一套能用于生产的 MySQL，我至少得操心这些事：

这不是吓唬自己，清单里每一项我都做过部分。保守估计每月要花我大半天，这还没算半夜爬起来处理故障的隐性消耗。其中最容易被忽略的是第三行：备份不是设置了就行，还得定期验证真的能恢复。很多自建方案的备份脚本跑了半年，出事才发现文件是空的、或者格式根本导不回来——我见过太多人把备份脚本当作已完成的备份，这两者之间差着十万八千里。

三、责任边界：谁在替你值夜班

把两个方案摆在一起看责任归属，思路会清楚很多：

发现规律没有：自建方案里所有责任都指向同一个人，就是你自己。你的精力是瓶颈，而云数据库把这些责任打包转移给了平台。这不是偷懒，而是分工——把标准化的基础设施交给专业的人，自己专注业务里真正有差异化的部分。

四、云数据库帮我省了什么

云数据库 MySQL（产品文档入口见云数据库 MySQL）把这些运维活打包成了服务，我对照清单重新算了一遍：

也有代价：超级管理账号拿不到，部分系统参数不能随便改，想装自定义插件没门。但我的业务就是增删改查为主，要的是稳，这些限制从头到尾没碰到过。换句话说，云数据库牺牲的是极端定制自由，换来的是中位水平的稳定——而我恰恰只需要稳定。有一种折中思路也值得记一笔：把核心的、不能丢的数据放云数据库，把可重建的临时数据留在自建机器上，两边各取所长。不过对一个刚起步的小项目来说，维护两套数据栈本身就是负担，我最终一步到位全交给了云数据库。

五、贵不贵，换个算法

单看列表价，同规格的云数据库确实比一台 CVM 贵。但自建方案的真实成本要加上这些：

最后一行是压垮天平的砝码。数据无价，误删整库这种事在自建环境里大概率无法挽回，在云数据库里至少还有一条退路。那段惊险故事我放在 2.3，这里先不剧透。

这笔账我没停在概念层面，真按第一年的量级拆了一遍。下面是我按最低可用配置估的第一年自建成本明细，价格都是按活动价的大概估算，具体以页面为准：

机器钱加起来其实不比一个入门云数据库实例贵多少，真正把天平压翻的是最后两行：人工时间没法砍价，误操作容错没法补救。

什么情况下我会反过来选自建？大致是这两条：一是有专职 DBA、数据量大到需要深度定制内核和参数；二是对数据驻留有特殊要求，必须自己掌握物理机器。二者我都不沾边，所以这笔账很快就算完了。身边也有朋友选了自建，理由是手里有闲置机器、又享受折腾的乐趣——这没什么不对，前提是他确实享受并且有空。每个人处境不同，我只是把我的处境如实算在这里。

做决定那天晚上我又问了自己一个问题：三年后我希望自己最强的一点是什么？是会把 MySQL 主从搭得比别人溜，还是有一个跑得稳、用户在长的产品？答案显然是后者。自建积累的是运维经验，云数据库买到的是专注业务的时间，而时间对独立开发者来说是不可再生的资源。

退一万步讲，就算云数据库某天涨价了、或者我想换回自建，数据导出迁移的路径始终是通的，这笔投资不会打水漂。可见的退路让人敢于做决定，被锁死的选择才让人犹豫。

六、结论

业务规模小、没有专职 DBA 的时候，把 MySQL 交给云数据库、自己专注写业务代码，是最划算的分工。等哪天规模上去了再考虑自建也完全来得及，云数据库的导出和迁移路径是通的，具体做法见 2.3。给还在犹豫的同学一句大实话：能省下运维精力的方案，长期看都便宜；省下来的时间投入产品，回报率远高于一台机器的差价。

文末帮大家要了个福利：云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中，我第一次买数据库实例就是从活动页下手的，新用户价格比列表价友好不少，试错成本也低。

顺带一提，服务器上的建站环境和管理面板怎么搞，可以看我另一本1Panel 运维面板实战；服务器和数据库出故障的排查套路，我在1Panel 常见问题里整理过一份清单。如果你想先把站跑起来再慢慢补数据库知识，AI 建站实战是条捷径。

下一篇讲具体操作：实例规格怎么选、高可用版和基础版怎么取舍、账号权限怎么划分、内外网地址怎么管。这几件事都在实例买完的第一天完成，属于一次性投入、长期受益的步骤，值得花一个整下午慢条斯理地做扎实。

还有一句实话要补：选了云数据库不等于万事不管，该学的数据库知识一点也不能少——索引、执行计划、事务隔离级别，这些在自建和云上是通用的。云数据库替你兜住的是运维和容错，不是替你写好 SQL。这个分工想清楚了，后面的章节才读得顺。

延伸阅读

• 云数据库 MySQL 官方文档
• 1Panel 常见问题
• AI 建站实战