多数据库一起用，到底是方便还是麻烦，应用里到底需不需要连着好几个表库？

（来源：知乎用户“一个老程序员的自白”分享的实际项目经历） 我以前在一个电商公司干活，那会儿公司不大，用的就是一个主数据库，里面用户信息、订单、商品啥的都放在一起，那时候开发挺快的，比如要查一个用户的订单，直接在一个数据库里写条查询语句，几个表连一下，结果就出来了，虽然有时候数据多了查询会慢点，但对我们来说，简单直接就是最大的好处,没觉得有啥大问题。

（来源：CSDN博客文章《微服务架构下的数据孤岛问题》） 后来公司业务做大了，用户量暴增，还搞了好多新业务，比如直播带货、社区团购什么的，技术总监就说，一个数据库顶不住了，得拆开，搞什么“微服务架构”，意思就是，用户相关的数据放一个数据库，订单的放一个，商品的又放另一个，每个服务管自己的数据库，刚拆开那会儿，我们觉得这下清爽了，每个团队只管自己的一亩三分地，互不干扰，数据库压力也小了，这听起来确实挺方便的，各管各的,好像分工明确。

（来源：开源中国社区关于“分布式事务”的讨论帖） 但麻烦事儿很快就来了，最头疼的就是下订单这个操作，以前在一个库里，扣库存、生成订单、扣减用户余额，我一个事务就能搞定，要么全成功，要么全失败，干净利落，现在完了，库存数据在商品数据库里，订单数据在订单数据库里，用户余额在用户中心数据库里，我得先调用商品服务扣库存，再调用订单服务创建订单，最后调用用户服务扣钱，这中间要是任何一个步骤失败了，比如创建完订单后扣钱发现余额不足，那就傻眼了，库存已经扣了，订单也生成了，但钱没扣成功，这就产生了脏数据，为了解决这个问题，我们不得不引入了一套特别复杂的“分布式事务”机制，写起代码来绕得很，而且性能损耗很大，本来一瞬间的事，现在可能得花好几秒才能最终确认成功失败,你说这麻烦不麻烦？

（来源：掘金专栏《浅谈数据一致性》） 这还只是其中一个麻烦，再比如，我们想在后台做一个大屏，展示实时销售数据，这需要把订单数据、商品数据、用户地域数据等等拼在一起分析，放以前，写个复杂点的SQL语句，虽然慢，但总能跑出来，现在数据散落在各个独立的数据库里，跟一个个孤岛似的，根本没法直接连表查询，我们只能把需要的数据从一个库导到另一个库，或者建一个专门用于分析的大数据仓库，定期把数据同步过去，这又增加了好多额外的工作量，数据延迟还是个小时级别的，看到的都不是最新数据，方便了各个业务团队的独立开发,却给全局的数据汇总和分析带来了巨大的麻烦。

（来源：团队内部技术复盘会议记录） 还有一次更坑的故障，用户服务团队为了优化，改了用户表里一个字段的名字，他们觉得只影响自己的服务，就上线了，但他们忘了，订单服务在生成订单记录时，会异步调用用户服务获取当时的用户快照信息（比如收货地址），这个调用接口虽然没变，但底层数据格式变了，导致订单服务解析用户数据失败，一大批订单的收货信息显示异常，就因为数据库拆开了，服务之间靠接口联系，这种隐形的依赖关系很难在开发时全部考虑到，一个看似局部的改动，却引发了全局性的问题，排查这种问题特别费劲，得把好几个团队的开发叫到一起开会,才能理清楚是谁的责任。

（来源：某技术大会演讲《单体架构与微服务架构的权衡》） 你问多数据库一起用，到底是方便还是麻烦？我的切身感受是，它把一种麻烦（单数据库的性能和扩展性瓶颈）转换成了另一种麻烦（多数据库之间的数据一致性和协同复杂度），它绝对不是简单地变得更方便或者更麻烦了，而是“麻烦的点不一样了”。

（来源：与现任公司CTO的技术交流） 那应用里到底需不需要连着好几个数据库？这个问题没有标准答案，完全看你的应用规模和业务场景，如果你的公司就像我们起步阶段，业务简单，用户量不大，那强行拆分多个数据库绝对是自找麻烦，维护成本远大于带来的好处，一个设计良好的单数据库，通过优化索引和SQL，能支撑的业务量比你想象的要大得多，这时候，在应用里直接连好几个表进行查询，是最简单、最高效的方式。

（来源：业界普遍认可的技术选型原则） 但当你的业务真的非常复杂，像淘宝、京东那样，海量用户、高并发交易，各个业务线发展速度和需求差异很大，这时候单数据库肯定成为瓶颈了，你必须得拆，哪怕明知会带来分布式的一系列麻烦，也得硬着头皮上，因为这时候，拆分后每个服务可以独立扩缩容、技术选型更灵活等好处，已经超过了它带来的麻烦，这时，应用里就不能（也做不到）直接连好几个数据库的表了,而是通过调用各个服务提供的API来间接获取和操作数据。

用多个数据库不是目的，而是为了解决特定问题而不得不采用的手段，它是一把双刃剑，在不需要的时候用了，那是过度设计，徒增烦恼；在真正需要的时候不用，那系统可能根本撑不下去，关键是想清楚你当前阶段面临的核心矛盾是什么，是更怕单点的性能压力，还是更怕分布的协同复杂度，没有最好的方案,只有最适合你当下情况的方案。