上周和一个做电商的老朋友吃饭，他跟我吐槽说，双十一那会儿系统崩了三次。客服那边急得跳脚，技术团队通宵排查，发现是数据库扛不住了。他说，早知道当初选部署方案时多花点心思，也不至于现在被老板骂得狗血淋头。这事让我挺有感触，数据库部署看似是技术活，实际上全是生意经。选对了，业务跑得顺风顺水；选错了，天天烧香求系统别出 bug。我见过太多创业公司，前期图便宜用共享数据库，等用户量上来才发现性能瓶颈像堵墙一样挡在前面，想换方案又怕数据迁移搞砸，进退两难。
说白了，数据库部署方案的核心就两条路：自建和上云。自建听起来挺美，服务器放在自己机房，数据全在自己手里，感觉特别踏实。但我一个做金融系统的朋友告诉我，自建数据库最头疼的不是技术，而是运维。服务器坏了要修，硬盘满了要扩容，还要防黑客攻击。他们公司为了养三个 DBA，一年光工资就砸进去小两百万。再加上机房租金、电费、硬件迭代，算下来并不比云服务便宜。更别提业务高峰期，系统响应慢得像蜗牛，想临时加机器，采购流程走完至少两周，黄花菜都凉了。所以，自建适合有专业团队、业务稳定的大厂，小公司真玩不起。
云数据库这几年火得不行，AWS 的 RDS、阿里云的 PolarDB、腾讯云的 TDSQL，各家都在抢着推。我接触过一家在线教育公司，用户量从几千涨到几十万，数据库从单机 MySQL 升级到分布式集群，全程没停机，靠的就是云服务的自动弹性伸缩。他们 CTO 说，最爽的是不用操心备份和灾备，云平台自动做三副本存储，出故障秒级切换。但云服务也有坑，比如计费模式复杂，按需付费看着便宜，跑起来才发现 IOPS 和存储分开计费，月底账单能吓死人。还有数据安全问题，虽然云厂商拍胸脯说加密，但出了事责任很难划清。
说到混合部署，现在很多公司玩得很溜。把核心业务数据放在自建机房，非核心业务放在云端，两头讨好。我认识一个做医疗器械的老板，他们的患者信息必须存本地满足合规要求，但线上预约系统又需要快速扩容。于是他们把患者库放在私有云，用 Oracle RAC 做高可用；预约系统跑在公有云上，用 Redis 缓存扛流量。这种方案听起来完美，但实际运维复杂度翻倍。既要维护两套环境，又要搞数据同步，稍不注意就会出现延迟或冲突。一次他们业务部门发现线上预约数据和本地患者数据对不上，排查半天才发现是网络抖动导致同步脚本挂掉。
还有个趋势是分布式数据库，比如 TiDB、OceanBase，这几年在金融、电商领域特别火。它们最大的好处是横向扩展，加几台机器性能就上去了。我采访过一家支付公司，他们用 TiDB 替换了原来的 MySQL 分库分表方案，开发效率提高了一大截。以前搞跨库查询要写好几层中间件，现在一条 SQL 就能搞定。但分布式数据库也不是万能药，对事务一致性要求高的场景，性能损耗很大。而且学习成本高，很多 DBA 连 MySQL 都没玩透，突然要搞 TiDB，培训就得花几个月。
说到底，选数据库部署方案没有标准答案，全看业务场景。我建议创业公司起步时先用云数据库的按量付费模式，等业务跑通、数据量上来再考虑是否迁移。千万别一上来就砸钱自建，万一产品方向错了，那些服务器和机房的投入全都打水漂。老牌企业倒是可以逐步上云，先把不敏感的业务搬上去试水，积累经验。但有一条铁律：不管选哪种方案，一定要做好数据备份和灾备演练。我见过太多公司，平时不备份，出事才哭爹喊娘，结果数据恢复不了，直接倒闭。
说个真实案例。我前同事在的一家物流公司，去年把核心数据库从自建 MySQL 迁移到云上的分布式数据库。迁移过程花了三个月，中间经历了两次回滚，一次是因为数据一致性校验没过，一次是因为性能压测不达标。但他们很聪明，先做了双写方案，新老数据库同时跑，等稳定后才切流。现在系统稳定运行，双十一峰值 QPS 从原来的一万飙到五万，运维成本反而下降了 30%。你看，数据库部署最怕的不是技术选型失误，而是没有试错和回退的预案。技术方案永远在变，但业务不能停，这才是最实在的道理。
