程序员修神之路--作好分库分表其实很难之一（继续送书）

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

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

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

作一个系统我以为不该该从数据库入手，应该从设计业务模型开始，先不说这个，说说你的数据库设计的优点

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

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

我以为分库分表很容易呀

是吗？

是否须要分

说到数据库分库分表，不能一味的追求，咱们要明白为何要进行分库分表才是最终目的。如今网上一些人鼓吹分库分表如何应对了多大数据，殊不知针对不少人的业务来讲，分库分表策略也许并不是是银弹，而是使人焦虑的焦油坑。

分库分表是业务发展到必定阶段，数据积累到必定量级而衍生出来的解决方案。当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模型如此优秀🤠 ●程序员过关斩将--论商品促销代码的优雅性 ●程序员过关斩将--你的面向接口编程必定对吗？ ●程序员修神之路--高并发下为何更喜欢进程内缓存 ●程序员修神之路--高并发优雅的作限流

原文出处：https://www.cnblogs.com/zhanlang/p/11143657.html