点击上方“蓝字”带你去看小星星

菜哥，领导让我开发新系统了

这么说领导对你还是挺信任的呀~

必须的，为了设计好这个新系统，数据库设计我花了好多心思呢

做一个系统我觉得不应该从数据库入手，应该从设计业务模型开始，先不说这个，说说你的数据库设计的优势

为了高性能我首先设计了分库 分表策略，为以后打下基础

那你的数据量将来会很大吗？分库分表其实涉及到很多难题，你了解过吗？

我觉得分库分表很容易呀

是吗？

是否需要分

说到数据库分库分表，不能一味的追求，我们要明白为什么要进行分库分表才是最终目的。现在网上一些人鼓吹分库分表如何应对了多大数据，却不知针对很多人的业务来说，分库分表策略也许并非是银弹，而是令人焦虑的焦油坑。

分库分表是业务发展到一定阶段，数据积累到一定量级而衍生出来的解决方案。当DB的数据量级到达一个阶段，写入和读取的速度会出现瓶颈，即使是有索引，索引也会变的很大，而且数据库的物理文件大的会使备份和恢复等操作变的很困难。这个时候由于DB的瓶颈已经严重危害到了业务，最有效的解决方案莫过于DB的分库分表了。

有的leader甚至架构师会在业务初期以自己的主观意愿就进行分库分表，会为以后业务高速发展做铺垫。但是这里我要表达我几个观点：

1. 如果当前这个业务并非公司的核心业务，而且在业务是否能存活的前提下，初级的设计不要这么复杂。如果每个业务我们都按淘宝那样的规模做系统架构设计，将来不但会害死业务，更会让程序员死的更惨，背上黑锅的数量会更多。

2. 单台数据库的能力并非想象中那么脆弱。就算是mysql单表数据量大部分场景下也在百万级别（当然这和存储的具体数据格式有关），sqlserver更是不在话下，我司用的sqlserver，单表千万级别数据的大有所在，亿级的也有几个，Oracle更是不用多说。

3. 如果业务周期比较短，或者人力物力不足的情况下，盲目的在初期就进行分库分表设计，更是给自己下了绩效背D的套，

4. 系统的设计初期和公司的基础数据有直接关系，比如微信这样的数据规模，稍微一个小系统就有可能是千万甚至上亿的数据级别，但是多数初创公司有多少能有这样的级别呢？我这里喷一句：有的创业公司号称从XX大公司重金挖来的CTO，技术总监等等高人，尤其是这些带着金色光环的人在创业初期给开发人员埋雷，一个创业公司搞一套XX分布式，XX设计，殊不知，在当前的公司环境下这些其实没有必要，给公司带来的更多是苦不堪言。

一个好的系统设计者会在开始设计之初，充分考虑到各方面的综合因素来综合考虑。

分   库

根据业务划分

说到分库，菜菜这里想多啰嗦一句：推荐大家根据业务来进行划分，我一直在过去的文章中强调，一个系统的好坏，业务的边界划分起到举足轻重的作用。业务按照规则划分好边界，每个业务对应的数据库自然而然就诞生了，不要站在数据库的层面上去给业务分库。有的leader会有这样的行为：某个表的数据量太大，分配到单独的一个库，结果导致的结果就是很多SQL语句必须跨库Join。

具体的业务怎么划分呢？这个规则我不敢说，每个公司的业务形态不同，划分的维度就会不同。举一个简单的例子：一个典型的电商系统根据业务可划分为商品，订单，这也是许多公司的典型业务划分，但是我司根据自己的业务规则，划分为商品，订单，支付。因为支付系统在我司是一个独立的业务，不但包含了订单的支付，还包含了很多其他的支付场景。根据业务上的划分，DB的层面就出现了商品DB，订单DB和支付DB。

同一业务横向划分

除了根据业务垂直切分的策略之外，还有另外一种常用的分库方案，如果某个具体业务数据量比较大，可以把这业务的数据库根据某种规则来进行横向切分。比如用户信息的业务，当用户量达到一定量级，有些公司会把用户信息拆分到多个数据库，说到这里，有的同学会问，这和拆分到多个表有什么区别呢？如果把用户信息横切到同一个数据库的多个表，如果这些表位于一个物理磁盘上，对于提高这个业务的写入和读取IO最大值并没有什么用处，但是如果分配到多个服务器上，意味着这个业务整体的最大IO得到了提升，在一定程度上要比拆表效果要好，当然如果用到了表分区，每个分区散落在不同的物理磁盘上，也不一定比分库方式差。

把某个业务的DB按照规则横向切分之后，当然也会引入新的问题，下边会介绍。切分的规则在很多情况下用的最多的就是哈希取余的方式了，有时间咱们在讨论。

分库引入复杂性

我在上文提到过，分库分表并非是银弹，任何一种解决方案能解决一个问题，但是有可能会引入其他问题，世界是公平的，计算机世界亦如此。那分库会引入哪些问题呢？

1. 在执行了分库之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们多数情况下无法join位于不同分库的表（因为多数公司都明令禁止跨库sql），结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

2. 原来在单体DB环境下，可以用DB的事务来保证一些操作的原子操作，但是在分散到多个数据库的情况下，统一管理这些操作变的困难。虽然一些大厂提供的也有跨库的事务解决方案，但是性能上实在是差强人意，所以在很多情况下并不实用。比如上边提到的商品库存支付，在单体应用的情况下，三个业务在同一个数据库，当发生支付业务，更改商品库存和更新订单状态这两个操作可以利用数据库提供的事物来完成，而且性能在可接受范围之内，如果这三个业务分布在不同的数据库，有几率会发生只执行其中一个操作的情况发生，其实这也是分布式事物要解决的问题。在很多情况下，分布式事物是无法避免的，根据业务综合情况适当采用分布式事物也是一种有效的解决方案，最坏的情况下，可能需要人工介入了。

3. 分库对于DBA来说意味着工作量的成倍增加，原来只需要管理一个DB，现在却要管理N个DB，而且每个DB都需要备份，监控，甚至做高可用，扩展等工作。原来可能只需要一个DBA管理人员，分库之后可能会需要两个甚至三个，导致了公司在人力投入上的加大。

完

●程序员过关斩将--你为什么还在用存储过程？●程序员过关斩将--小小的分页引发的加班血案●程序员修神之路--问世间异步为何物？●程序员修神之路--提高网站的吞吐量?●程序员修神之路--?分布式高并发下Actor模型如此优秀?●程序员过关斩将--论商品促销代码的优雅性●程序员过关斩将--你的面向接口编程一定对吗？●程序员修神之路--高并发下为什么更喜欢进程内缓存●程序员修神之路--高并发优雅的做限流