我见过太多创业公司，技术团队一开始就照着BAT的架构去搭数据库。服务器配了一堆，中间件上了七八个，结果用户才几千，天天在那调优，业务根本跑不起来。等到真正流量上来的时候，发现这堆东西反而成了累赘。其实数据库架构这件事，核心就一句话：什么时候做什么事，别提前焦虑，也别后知后觉。
单库单表是绝大多数业务系统的起点。你想想，用户量不过万的时候，一台MySQL就能扛住大部分场景。我有个朋友做电商SaaS，早期就一台8核32G的机器，日活两千，订单表一天也就几千条数据。他担心将来撑不住，非要上分库分表，结果开发周期拉长了两周，上线后连个性能瓶颈都没碰到。单库单表的问题在于，它确实有天花板——一般单表数据超过500万行，或者并发写入超过每秒2000次，MySQL就开始吃力了。但这个天花板对你的业务来说，可能是一年甚至两年后的事。别为了两年后的风险，耽误现在的产品迭代。
当单库确实扛不住的时候，第一步不是分库分表，而是读写分离。这个方案简单到令人发指：主库写，从库读，中间加个负载均衡。我去年帮一个在线教育平台做咨询，他们的课程表查询占了总请求的80%，写操作只有20%。DBA之前一直在折腾分表，把课程表按季度拆成12张表，代码改得面目全非。我建议他先试试读写分离，配两个从库，一周时间就搞定了。结果查询延迟从50毫秒降到了5毫秒，主库的压力也降了70%。读写分离的适用范围很明确：读多写少、对一致性要求不那么变态的业务。如果你的业务是转账或者库存扣减，那得另外想办法。
分库分表是很多技术人的噩梦，不是因为它难，而是因为它一旦上了，就回不了头。分库分表的本质是把一张大表拆成多张小表，分散到不同数据库里。常见的方式有两种：垂直分库和水平分表。垂直分库是按业务模块来拆，比如把用户数据放在用户库，订单数据放在订单库。水平分表是按某个字段来散列，比如按用户ID取模，把数据分散到32张表里。我做过的项目里，有个社交产品的用户关系表，拆完之后单表数据从2亿降到了600万，查询速度提升了10倍。但代价是业务代码里到处都是路由逻辑，每个查询都得先算数据在哪个分片。更麻烦的是，跨分片的查询和事务几乎没法做。所以分库分表前一定要想清楚：你的业务真的需要吗？能不能用缓存或者NoSQL替代？
分库分表之后，最头疼的问题就是跨分片查询和分布式事务。比如你要查某个用户过去三个月的订单，但订单表是按订单ID分片的，用户ID和订单ID没有对应关系。这时候你只能全量扫描所有分片，再把结果合并回来。这就是典型的“扫全表”问题。我见过一个团队，分库分表后上线第一天就崩了，就因为一个后台统计功能需要跨所有分片查询，数据库连接池直接被打满。解决方案有几条路可以走：一是业务上规避，不让用户做跨分片的查询；二是用ES或搜索引擎做二级索引，把查询需求转给搜索引擎；三是用ShardingSphere这类中间件，它帮你做SQL改写和结果合并。没有银弹，只有取舍。
缓存是数据库架构里最被低估的组件。很多人以为缓存就是Redis存个key-value，给热点数据加速。实际上，用好缓存能直接干掉数据库90%的读压力。我认识一个短视频平台的架构师，他们的做法是：把所有用户的首页推荐结果预计算好，直接存到Redis cluster里。用户刷首页的时候，99%的请求都打在Redis上，数据库几乎不参与。缓存的设计关键在两点：一是过期策略，别让数据一直堆着；二是缓存穿透保护，别让大量请求落到数据库上。最常见的做法是布隆过滤器加本地缓存，双重保护。记住，缓存不是银弹，但它是第一道防线。
NoSQL数据库在亿级流量场景下不是替代品，而是补充。很多团队犯的错误是：一看到关系型数据库撑不住了，就想着全量迁移到MongoDB或者Cassandra。结果发现NoSQL不支持复杂查询，没法做join，事务支持也弱，搞出个四不像。正确的做法是：把适合NoSQL的业务剥离出去。比如用户行为日志、消息推送记录、点赞计数这些数据，用NoSQL存比MySQL舒服多了。我做过一个直播平台，礼物记录表每天产生上亿条数据，用MySQL根本扛不住。后来换成HBase，按时间戳做rowkey，写入速度直接翻了一百倍。MySQL只保留核心的业务数据，比如用户账户、订单、库存。
聊一下分布式数据库。这几年TiDB、OceanBase这些原生分布式数据库越来越成熟，它们的卖点就是解决分库分表带来的复杂性。你不需要自己拆表，不需要操心跨分片查询，集群自己搞定。我用过TiDB做金融级项目，它的强一致性确实让人放心，故障切换也能做到秒级。但问题是，分布式数据库的硬件成本比传统MySQL高。同样性能下，TiDB需要的机器数量可能是MySQL的三倍。而且它对复杂SQL的支持还在完善中，有些优化器行为不太可控。所以我的建议是：如果你的团队有足够的人力和经验，MySQL加中间件是性价比最高的方案。如果团队小，不想在基础设施上花太多精力，分布式数据库可以让你少踩很多坑。
从单库到分布式，没有一步到位的方案。每一步都有它的代价和适用场景。单库单表适合业务验证期，读写分离适合流量增长初期，分库分表适合数据量爆炸期，缓存和NoSQL是辅助手段，分布式数据库是兜底方案。别迷信技术，也别轻视风险。技术选型从来不是选最牛的，而是选最合适的。
