自己原文公众号： https://mp.weixin.qq.com/s/bbHGIoKpHBFyU8F0Bk1CHg
数据库分久必合合久必分。
20年前我们没什么人说架构，但是现在几乎是个人就说架构。为什么呢？因为从前是单机，而现在是多机。比如分库 或者分表。或者分布式。
这里再次说一下，分库分表不是分布式。分布式是一个库，分库分表是多个库。分布式是由分布式数据库来完成事务和锁。分库分表是应用自己来实现事务和锁。 另外分库相对容易，分表就比较难做。分库和分表是两回事。
微服务和中台是导致数据库分库的主要因素。但是这里要提一下分库不见得是要把数据库分在很多不同机器上。比如这也是分库。
这个也是
所以说分库，可以分，但是没说一定要多台机器呀。一个上面也可做很多database库。
每次说到这个我会面对一堆质疑，就是10个子系统，10个库。那么就要用10台机器安装数据库。我们之前说了分库不是分布式。那么10个库之间的事务和锁就要需要第三方来保障或者根本没保障。那这个一致性就比较惨不忍睹，即使有一个很好的控制，要知道所有的交互在网络上消耗了大部分。
所以我的观点：单套是最好的架构。比如Oracle的RAC，以及MySQL的MGR和国产数据库TiDB 等等分布式数据库都是一套 。因为要高可用嘛。如果不要高可用，我认为单机是最好的架构。
这里必须说质疑单机坏了怎么办？我干了快20年，单机除了自己做实验各种破坏性的把底层文件全部删除起不来的，还没有遇到过数据库自己运行着然后起不来的。我相信也有，但是更多的情况是应用写的太差把数据库搞得宕机的。如果说比例那么破坏性的如果是1，那么应用导致的我估计说是1000万也不过分。比例大概是1000万比1. 根据这个比例我觉得重要精力还是花在更容易出问题的点上。毕竟现如今的硬件质量杠杠的，再加上RAID10，硬盘坏50%也还行。
这里也有人说10个库一个宕机（就是应用写的差），不影响其他9个啊。其他还能用。问题是10个如果是独立事件的，那么自然是这样的。但是如果是有紧耦合或者前后关系的。比如会员库故障，无法登录了，后面的事情都别做了。 订单库故障，就算能登录，今天也别干了。
这里我还说一点但凡这种场景下一个能宕机，放心，其他几个也会宕机。所以数据库越来越多，因为把数据不停的分散，降低表的数据量，从而提升全表查询的时间。时间短了，锁短了，CPU少了。但是这一切就是头痛医头脚痛医脚，越来越差。很多人问我A和B库能不能和在一起？我就问你们有开发规范吗？如果有能执行吗？能执行的话就放在一起。没有规范或者不能执行规范就别放在一起。
开发规范能解决这些问题吗？
能！
绝大多数故障99.9%都是性能问题导致的。如果你看过我星辰大海的那几篇公众号文章就知道了，单机足以支持你的业务。如果不能支持你的业务，那么你应该已经是财务自由的人或者是年薪百万的人。因为你的体量已经很大很大了。
我以前看到过这样一个案例：
整合是大量节约成本的。
还是回到那个让人揪心的问题。和在一起故障怎么办？答案还是一样，有规范吗？我们高铁16节车厢，1000人总有吧？出了温州那次意外就没怎么出过事故。你能说1000多人有风险？反过来说两座的跑车，酒驾车毁人亡的多了去了。要是胡来怎么都不行！
就算是高可用也不是用来解决性能问题的，那是防止意外的。
