1 导读各位小伙伴，在目前企业级开发中采用Mysql做为数据库是一个主流选择，而当数据量比较大的情况下，为了支撑项目的正常快速的运行，我们不得不选择对数据库分库分表操作，本章节就对数据库的分表做一些方案的讲解，包括如下：

为什么要分库分表分库分表的具体方式分库分表带来的问题及解决方案有哪些2 为什么分库分表 随着平台的业务发展，数据可能会越来越多，甚至达到亿级以MySQL为例，单库数据量在5000万以内性能比较好，超过阈值后性能会随着数据量的增大而明显降低。

单表的数据量超过1000w，性能也会下降严重这就会导致查询一次所花的时间变长，并发操作达到一定量时可能会卡死，甚至把系统给拖垮 我们是否可以通过提升服务器硬件能力来提高数据处理能力？能，但是这种方案很贵，并且提高硬件是有上限的。

那我们能不能把数据分散在不同的数据库中，使得单一数据库和表的数据量变小，从而达到提升数据库操作性能的目的？ 可以，这就是数据库分库分表 分库分表就是把较大的数据库和数据表按照某种策略进行拆分目的在于：降低每个库、每张表的数据量，减小数据库的负担，提高数据库的效率，缩短查询时间。

另外，因为分库分表这种改造是可控的，底层还是基于RDBMS，因此整个数据库的运维体系以及相关基础设施都是可重用的3 分库分表的方式3.1 垂直分表 用户在电商平台流览商品时，首先看到的是商品的基本信息，如果对该商品感兴趣时才会继续查看该商品的详细描述。

因此，商品基本信息的访问频次要高于商品详细描述信息，商品基本信息的访问效率要高于商品详细描述信息(大字段) 由于这两种数据的特性不一样，因此考虑将商品信息表拆分如下：

这种拆分就叫垂直分表垂直分表定义：将一个表的字段分散到多个表中，每个表存储其中一部分字段垂直分表带来的提升是：减少IO争抢，减少锁表的几率，查看商品详情的与商品概述互不影响充分发挥高频数据的操作效率，对商品概述数据操作的高效率不会被操作商品详情数据的低效率所拖累。

一般来说，某业务实体中的各个数据项的访问频次是不一样的，部分数据项可能是占用存储空间比较大的BLOB或是TEXT，例如上例中的商品描述字段所以，当数据量很大时，可以将表按字段拆分，将热门字段、冷门字段分开放置在不同表中。

垂直切分带来的性能提升，主要集中在热门数据的操作效率上，而且磁盘争用情况减少通常我们按以下原则进行垂直拆分:把不常用的字段单独放在一张表把text，blob等大字段拆分出来单独放在一张表经常组合查询的字段单独放在一张表中。

3.2 垂直分库 通过垂直分表，数据库性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终存放在一台服务器库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻数据库的压力来说，作用有限，大家还是竞争同一个物理机的CPU、内存、网络IO、磁盘。

以电商平台为例，可以把原有的SELLER_DB(卖家库)，拆分为PRODUCT_DB(商品库)和STORE_DB(店铺库)，并把这两个库分散到不同服务器上，如下图所示：

由于商品信息与商品描述业务耦合度较高，因此一起被存放在PRODUCT_DB(商品库)；而店铺信息相对独立，因此单独被存放在STORE_DB(店铺库)，这就叫垂直分库垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，从而达到多个服务器共同分摊压力的效果。

垂直分库带来的提升是：解决业务层面的耦合，业务清晰能对不同业务的数据进行分级管理、维护、监控、扩展等高并发场景下，垂直分库在一定程度上可以提升IO、数据库连接数、单机硬件资源的性能3.3 水平分库 经过

垂直分表和垂直分库后，数据库性能问题就完全解决了？假设某电商平台发展迅猛，PRODUCT_DB(商品库)单库存储数据已经超出预估假设目前该平台有8w店铺，每个店铺平均有150个不同规格的商品，再算上增长，那商品数量就会达到1500w+级别，并且PRODUCT_DB(商品库)属于访问非常频繁的资源，性能瓶颈再次出现。

能再次垂直分库吗？从业务角度分析，目前已经无法再次垂直拆分于是我们又想了一个办法，判断商品ID是奇数还是偶数，然后把商品信息分别存放到两个数据库中也就是说，要操作某条数据，先分析这条数据的商品ID，如果商品ID为奇数，将此操作映射至RRODUCT_DB1(商品库1)；如果商品ID为偶数，将操作映射至RRODUCT_DB2(商品库2)，这就叫。

水平分库。

水平分库是把同一个表的数据按一定规则拆分到不同的数据库中，每个库可以放在不同的服务器上它带来的提升是：解决了单库大数据，高并发的性能瓶颈按照合理拆分规则拆分，join操作基本避免跨库。

提高了系统的稳定性及可用性 当一个应用难以再细粒度的垂直切分，或切分后数据量行数仍然巨大，存在单库读写、存储性能瓶颈，这时候就需要进行。

水平分库了，经过水平切分的优化，往往能解决单库存储量及性能瓶颈但由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大增加了系统复杂度3.4 水平分表 数据库能水平拆分，那数据表是不是也可以呢？我们尝试把某PRODUCT_DB(商品库)内的表，进行了一次水平拆分：。

与水平分库的思路类似，不过这次拆分的目标是表，商品信息及商品描述被分成了两套表如果商品ID为奇数，将此操作映射至商品信息1表；如果商品ID为偶数，将操作映射至商品信息2表，这就叫水平分表水平分表是在同一个数据库内，把同一个表的数据按一定规则拆分到多个表中。

它带来的提升是：优化单一表数据量过大而产生的性能问题避免IO争抢并减少锁表的几率 库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个表的数据量变小，提高检索性能但由于同一个表的数据被拆分为多张表，也需要额外进行数据操作的路由工作，因此增加了系统复杂度。

3.5 小结垂直分表：可以把一个宽表的字段按访问频次、业务耦合松紧、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。

但是它需要解决跨库带来的所有复杂问题水平分库：可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题。

水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。

若数据量极大，且持续增长，再考虑水平分库分表方案4 分库分表带来的问题 分库分表有效的缓轿用的自增长将无用武之地，某个分区数据库生成的ID无法保证全局唯一。

因此需要单独设计全局主键，以避免跨库主键重复问题

由于分库分表之后，数据被分散在不同的服务器、数据库和表中因此，对数据的操作也就无法通过常规方式完成，并且它还带来了一系列的问题我们在开发过程中需要通过一些中间件解决这些问题，市面上有很多中间件可供我们选择，其中Sharding-JDBC和mycat较为流行。

5 总结通过以上学习呢，我们知道，当数据库特别大的情况下，数据库存储数量达到了一定的阈值以后会变慢，我们需要使用分库分表的方案来解决这个问题我们主要学习了垂直分表、垂直分库、水平分表、水平分库四种方案当我们选择分库分表以后也会带来一些问题，比如事务一致的问题、垮节点聚合的问题、分页、主键避重等等问题，大家也要掌握这些问题的解决方案。