数据库分库分表到底是个啥，为什么现在都说要用它来应对大数据量？

主要整合自业界常见的系统架构设计讨论，如阿里巴巴《Java开发手册》、极客时间《后端存储实战课》等专栏中的相关概念普及，以及技术社区如CSDN、InfoQ上资深工程师的经验分享）

你有没有想过，一个超级大的图书馆是怎么管理几百万甚至上千万本书的？它肯定不会把所有书都塞进一个巨大的房间里，然后只用一套“A-Z”的字母顺序来排列，那样的话，找一本书可能会跑到断腿，现实中的大图书馆，通常会这么做：先把书按大的类别分到不同的阅览室，比如文学阅览室、历史阅览室、科技阅览室，这就是“分库”,每个阅览室就是一个独立的库。

在同一个阅览室里，比如文学阅览室，书又太多了，怎么办？它会再细分，比如按作者姓氏的首字母分区：A-F区、G-L区等等，这就是“分表”，把一个阅览室（库）里的书，分散到多个书架（表）上。

数据库的分库分表，道理跟这个一模一样，当一家公司的业务越来越红火，用户量上亿，每天产生的数据像洪水一样涌来时，那个最初设计来存储数据的单一数据库（就像只有一个阅览室的图书馆），就开始顶不住了,它会遇到几个大麻烦：

第一个麻烦是“性能瓶颈”，想象一下，所有借书还书的人都挤在一个柜台前排队，队伍会排得多长？数据库也是，所有的读写请求都集中在一台服务器上，这台服务器的CPU、内存、磁盘IO很快就会达到极限，结果就是，网站或App变得巨卡，点一下要等半天，这就像高峰期去热门餐厅吃饭,等位等到绝望。

第二个麻烦是“存储瓶颈”，一家小书店可能一个书架就够用了，但国家图书馆能用一个书架吗？同样，单台服务器的硬盘容量是有限的，当数据量增长到TB、PB级别时，一台机器根本存不下，比如短视频平台，用户上传的海量视频文件,就不是单个数据库能承受的。

第三个麻烦是“可用性风险”，俗话说“不要把鸡蛋放在一个篮子里”，如果整个图书馆就靠那一栋楼，万一这栋楼停电、漏水或者需要维修，那整个图书馆就彻底瘫痪了，谁也借不了书，单一的数据库服务器也是如此，一旦它出点硬件故障或者需要停机升级，整个服务就中断了,这是互联网应用无法接受的。

怎么解决这些麻烦呢？答案就是模仿大图书馆的管理方法——分库分表,它主要有两种拆分方式：

一种是垂直拆分，这很像“分库”，就是按业务功能把数据分开存，把一个庞大的数据库，拆分成“用户数据库”、“订单数据库”、“商品数据库”，这样，查询用户信息的请求就去用户库，下单支付的请求就去订单库，相当于把原来挤在一个柜台前的队伍，分流到了好几个专业柜台,压力自然就分散了。

另一种是水平拆分，这很像“分表”，当某一个业务的数据本身变得极其庞大时，比如用户库里的用户表，已经有5亿条记录了，查起来还是很慢，这时候就要“分表”，最常见的分法是根据某个字段（比如用户ID）的哈希值取模，把5亿用户数据均匀地切分成1024张甚至更多的表（表0，表1，...表1023），每张表只存大概50万条数据，查询速度就快多了，这些表可以放在同一台服务器上（这有时也叫分表），但如果一台机器还是扛不住，就可以把这些分表分别放到不同的服务器上去（这就是真正的分库分表结合了），这就好比文学阅览室的书还是太多，于是我们不仅按字母分了区，还把每个区的书架搬到了不同的楼层甚至不同的副楼里,进一步分散人流和藏书压力。

现在大家常说要用分库分表来应对大数据量，根本原因就是业务规模上来了，数据量和访问量暴增，传统的“单库单表”架构已经成了阻碍业务发展的瓶颈，通过分库分表，我们可以把数据和请求分散到多台性价比更高的普通服务器上，从而实现 scale-out（横向扩展），就像用很多台普通电脑组成一个超级计算机一样，共同承担压力，这样系统才能支撑起海量用户和高并发访问，保证速度快、不停机。

分库分表也不是银弹，它带来了很多新的挑战，以前在一个数据库里能轻松完成的多表关联查询，现在数据分散在不同的库和表里，变得非常困难，还有，如何保证数据能够相对均匀地分布，避免出现“数据倾斜”（某个库或表特别忙，其他很闲），以及跨库的事务如何保证一致性等问题，都需要在设计和实施时仔细考虑，在面对大数据量这个必然趋势时，分库分表是目前业界最主流、最成熟的解决方案之一。