预算有限选数据库，我把踩过的坑都列出来了

去年帮一家做本地生活的小公司做技术盘点，他们一年数据库账单接近18万，团队一共4个后端。老板问我一句话：这钱花得值吗。我翻了两个小时账单，发现至少有6万是白花的。预算紧的时候，选数据库这件事比写代码更容易烧钱，而且烧得悄无声息。

先算清楚钱到底花在哪

很多人比价只看实例规格那一行价格，实际账单里的项目比想象中多。我一般让团队先拉三个月的历史账单，把每一项占比算出来，再决定动哪块。

• 实例费用：云上8核16G的MySQL，包年大概一万五到三万，看厂商和地域
• 存储费用：SSD按GB计费，数据涨得比你想的快，尤其是日志表和埋点表
• 备份与快照：这块最容易忽略，我见过备份存储比主库存储还贵的单子
• 流量和连接：跨可用区、跨地域读写都会悄悄加钱
• 人力：自建看着省，但一个靠谱DBA的年薪顶好几台服务器

如果备份加存储超过总账单的30%，那基本不是选型问题，是数据没有清理策略。加个定时任务归档冷数据，一个月能省出一台测试机。

哪些钱能省，哪些碰都别碰

省钱的顺序很重要。我见过的典型做法是：先砍备份，再砍监控，最后出事的时候连日志都查不到。这是完全反过来的。

能省的是实例规格。业务早期并发低，2核4G跑MySQL绰绰有余，省下的预算换成一个只读实例扛高峰更划算。能用开源就别碰商业授权，PostgreSQL在不少场景里能替掉Oracle，省下的授权费够养半个团队。云厂商的Serverless数据库也值得看看，流量波动大的业务按量付费确实便宜，但要留意冷启动延迟和最大连接数的限制。

不能省的是备份，而且要异地、要定期做恢复演练。我遇到过一家公司备份文件齐全，真出事的时候恢复失败，因为从建库那天起就没试过恢复流程。省了演练那几个小时，赔进去的是整条业务线。

监控和慢查询日志也基本不花钱，但能让你在小问题变成大故障之前发现它。这两样我从来不给客户砍。

还有一点，预算有限的团队我一般不建议上分布式数据库。TiDB、CockroachDB这类东西单机跑起来不难，难的是出了问题谁来修。运维成本会远远超过你省下的那点硬件钱。

一个真实的迁移案例

前面提到那家本地生活公司，原来的方案是云上高配RDS加一堆按量付费的只读实例，账单一直在涨。我们做了三件事：把订单历史表按季度归档到对象存储，主库瘦身了七成；把两个只读实例换成定时任务里的离线报表库；备份策略从每天全量改成一全量加增量。

改完之后月账单从一万四降到六千多，读延迟反而更稳了。整个过程花了大概三周，主要时间耗在数据校验上，不是技术难度。说白了，大部分预算问题都不是数据库不够强，而是没人认真看过那张账单。

如果你现在也在抠预算，我的建议是先别急着换数据库产品，把账单拆开看一遍，把没用的索引、没人查的表、三个月前的日志清一清。能省下来的钱，通常比你换选型省得多。