MySQL垂直分表与⽔平分表
分库分表是什么
下边以电商系统中的例⼦来说明，下图是电商系统卖家模块的表结构： 通过以下 SQL 能够获取到商品相关的店铺信息、地理区域信息：
SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]FROM [商品信息] p
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码]LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]WHERE p.id = ?
随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，优化迫在眉睫。分析⼀下问题出现在哪⼉呢？ 关系型数据库本⾝⽐较容易成为系统瓶颈，单机存储容量、连接数、处理能⼒都有限。当单表的数据量达到 1000W 或 100G 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。 ⽅案 1：通过提升服务器硬件能⼒来提⾼数据处理能⼒，⽐如增加存储容量 、CPU 等，这种⽅案成本很⾼，并且如果瓶颈在 MySQL 本⾝那么提⾼硬件也是有很的。⽅案 2：
把数据分散在不同的数据库中，使得单⼀数据库的数据量变⼩来缓解单⼀数据库的性能问题，从⽽达到提升数据库性能的⽬的，如下图：将电商数据库拆分为若⼲独⽴的数据库，并且对于⼤表也拆分为若⼲⼩表，通过这种数据库拆分的⽅法来解决数据库的性能问题。
分库分表就是为了解决由于数据量过⼤⽽导致数据库性能降低的问题，将原来独⽴的数据库拆分成若⼲数据库组成 ，将数据⼤表拆分成若⼲数据表组成，使得单⼀数据库、单⼀数据表的数据量变⼩，从⽽达到提升数据库性能的⽬的。
垂直分表
分库分表包括分库和分表两个部分，在⽣产中通常包括：垂直分库、⽔平分库、垂直分表、⽔平分表四种⽅式。 先说 垂直分表： 通常在商品列表中是不显⽰商品详情信息的，如下图：
⽤户在浏览商品列表时，只有对某商品感兴趣时才会查看该商品的详细描述。因此，商品信息中商品描述字段访问频次较低，且该字段存储占⽤空间较⼤，访问单个数据 IO 时间较长；商品信息中商品名称、商品图⽚、商品价格等其他字段数据访问频次较⾼。由于这两种数据的特性不⼀样，因此他考虑将商品信息表拆分如下：
将访问频次低的商品描述信息单独存放在⼀张表中，访问频次较⾼的商品基本信息单独放在⼀张表中。 商品列表可采⽤以下 sql：
SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]FROM [商品信息] p
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码]LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]WHERE...ORDER BY...LIMIT...
需要获取商品描述时，再通过以下 sql 获取：
SELECT *
FROM [商品描述] WHERE [商品ID] = ?
垂直分表定义：将⼀个表按照字段分成多表，每个表存储其中⼀部分字段。 它带来的提升是：为了避免 IO 争抢并减少锁表的⼏率，查看详情的⽤户与商品信息浏览互不影响
充分发挥热门数据的操作效率，商品信息的操作的⾼效率不会被商品描述的低效率所拖累。
为什么⼤字段 IO 效率低：第⼀是由于数据量本⾝⼤，需要更长的读取时间；第⼆是跨页，页是数据库存储单位，很多查找及定位操作都是以页为单位，单页内的数据⾏越多数据库整体性能越好，⽽⼤字段占⽤空间⼤，单页内存储⾏数少，因此 IO 效率较低。第三，数据库以⾏为单位将数据加载到内存中，这样表中字段长度较短且访问频率较⾼，内存能加载更多的数据，命中率更⾼，减少了磁盘 IO，从⽽提升了数据库性能。
⼀般来说，某业务实体中的各个数据项的访问频次是不⼀样的，部分数据项可能是占⽤存储空间⽐较⼤的 BLOB 或是 TEXT。例如上例中的商品描述。所以，当表数据量很⼤时，可以将表按字段切开，将热门字段、冷门字段分开放置在不同库中，这些库可以放在不同的存储设备上，避免 IO 争抢。垂直切分带来的性能提升主要集中在热门数据的操作效率上，⽽且磁盘争⽤情况减少。
通常我们按以下原则进⾏垂直拆分:把不常⽤的字段单独放在⼀张表;
把 text，blob 等⼤字段拆分出来放在附表中;经常组合查询的列放在⼀张表中;
垂直分库
通过垂直分表性能得到了⼀定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终在⼀台服务器，库内垂直分表只解决了单⼀表数据量过⼤的问题，但没有将表分布到不同的服务器上，因此每个表还是竞争同⼀个物理机的 CPU、内存、⽹络 IO、磁盘。
经过思考，他把原有的 SELLER_DB(卖家库)，分为了 PRODUCT_DB(商品库) 和 STORE_DB(店铺库)，并把这两个库分散到不同服务器，如下图： 由于商品信息与商品描述业务耦合度较⾼，因此⼀起被存放在 PRODUCT_DB(商品库)；⽽店铺信息相对独⽴，因此单独被存放在 STORE_DB(店铺库)。垂直分库是指按照业务将表进⾏分类，分布到不同的数据库上⾯，每个库可以放在不同的服务器上，它的核⼼理念是专库专⽤。它带来的提升是：
解决业务层⾯的耦合，业务清晰
能对不同业务的数据进⾏分级管理、维护、监控、扩展等
⾼并发场景下，垂直分库⼀定程度的提升 IO、数据库连接数、降低单机硬件资源的瓶颈
垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从⽽达到多个服务器共同分摊压⼒的效果，但是依然没有解决单表数据量过⼤的问题。
⽔平分库
经过垂直分库后，数据库性能问题得到⼀定程度的解决，但是随着业务量的增长，PRODUCT_DB(商品库) 单库存储数据已经超出预估。粗略估计，⽬前有 8w 店铺，每个店铺平均150 个不同规格的商品，再算上增长，那商品数量得往 1500w + 上预估，并且 PRODUCT_DB(商品库) 属于访问⾮常频繁的资源，单台服务器已经⽆法⽀撑。此时该如何优化？再次分库？但是从业务⾓度分析，⽬前情况已经⽆法再次垂直分库。
尝试⽔平分库，将店铺 ID 为单数的和店铺 ID 为双数的商品信息分别放在两个库中。
也就是说，要操作某条数据，先分析这条数据所属的店铺 ID。如果店铺 ID 为双数，将此操作映射⾄ RRODUCT_DB1(商品库 1)；如果店铺 ID 为单数，将操作映射⾄RRODUCT_DB2(商品库 2)。此操作要访问数据库名称的表达式为 RRODUCT_DB[店铺 ID%2 + 1] 。⽔平分库是把同⼀个表的数据按⼀定规则拆到不同的数据库中，每个库可以放在不同的服务器上。
垂直分库是把不同表拆到不同数据库中，它是对数据⾏的拆分，不影响表结构
它带来的提升是：
解决了单库⼤数据，⾼并发的性能瓶颈。提⾼了系统的稳定性及可⽤性。
稳定性体现在 IO 冲突减少，锁定减少，可⽤性指某个库出问题，部分可⽤ `
当⼀个应⽤难以再细粒度的垂直切分，或切分后数据量⾏数巨⼤，存在单库读写、存储性能瓶颈，这时候就需要进⾏⽔平分库了，经过⽔平切分的优化，往往能解决单库存储量及性能瓶颈。但由于同⼀个表被分配在不同的数据库，需要额外进⾏数据操作的路由⼯作，因此⼤⼤提升了系统复杂度。
⽔平分表
按照⽔平分库的思路对他把 PRODUCT_DB_X(商品库) 内的表也可以进⾏⽔平拆分，其⽬的也是为解决单表数据量⼤的问题，如下图：
与⽔平分库的思路类似，不过这次操作的⽬标是表，商品信息及商品描述被分成了两套表。如果商品 ID 为双数，将此操作映射⾄商品信息 1 表；如果商品 ID 为单数，将操作映射⾄商品信息 2 表。此操作要访问表名称的表达式为商品信息 [商品 ID%2 + 1] 。⽔平分表是在同⼀个数据库内，把同⼀个表的数据按⼀定规则拆到多个表中。它带来的提升是：
优化单⼀表数据量过⼤⽽产⽣的性能问题避免 IO 争抢并减少锁表的⼏率
库内的⽔平分表，解决了单⼀表数据量过⼤的问题，分出来的⼩表中只包含⼀部分数据，从⽽使得单个表的数据量变⼩，提⾼检索性能。
总结
垂直分表：可以把⼀个宽表的字段按访问频次、是否是⼤字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务⾓度避免联查，否则性能⽅⾯将得不偿失。
垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从⽽使访问压⼒被多服务器负载，⼤⼤提升性能，同时能提⾼整体架构的业务清晰度，不同的业务库可根据⾃⾝情况定制优化⽅案。但是它需要解决跨库带来的所有复杂问题。
⽔平分库：可以把⼀个表的数据 (按数据⾏) 分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从⽽使访问压⼒被多服务器负载，⼤⼤提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。
⽔平分表：可以把⼀个表的数据 (按数据⾏) 分到多个同⼀个数据库的多张表中，每个表只有这个表的部分数据，这样做能⼩幅提升性能，它仅仅作为⽔平分库的⼀个补充优化。⼀般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表⽅案，在数据量及访问压⼒不是特别⼤的情况，⾸先考虑缓存、读写分离、索引技术等⽅案。若数据量极⼤，且持续增长，再考虑⽔平分库⽔平分表⽅案。
