什么是分库分表？ 以下以电子商务系统为例进行说明。 下图是电子商务系统卖方模块的表结构。
在以下SQL中，可以获得有关商品的店铺信息、地理信息。
SELECT p.*，r.[地理区域名称]，s.[商店名称]，s.[gxdxh]FROM [商品信息] p LEFT JOIN [地理区域] r ON p.[产地]=r.[地理区域代码]LEFT JOIN [商店分析一下问题在哪里吧？ 关系数据库本身容易成为系统瓶颈，独立存储器的容量、连接数和处理能力有限。 在单表数据量达到1000W或100G后，由于查询维数较大，即使从库中添加索引或优化索引，大量操作也会导致性能严重下降。
方案1 :
提高服务器硬件能力和数据处理能力(包括增加存储容量和CPU )是昂贵的。 此外，瓶颈越位于MySQL本身，硬件也可以越好。
方案2 :
其目的是通过将数据分布在不同的数据库中，减少单个数据库的数据量，从而缓解单个数据库的性能问题，提高数据库性能。 如下图所示，通过将电子商务数据库划分为几个独立的数据库，将xndkn也划分为几个小表来解决数据库的性能问题。
分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成 ，将数据xndkn拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。
垂直分割表分割表包括分割表和分割表两部分，生产中通常包括垂直分割表、水平分割表、垂直分割表、水平分割表四种方式。
首先说垂直分表：
通常，商品列表不显示商品的详细信息。 如下图所示。
用户在浏览商品清单时，只有在对某个商品感兴趣的情况下，才会看到该商品的详细说明。 因此，商品信息中商品描述字段的访问频率低，且存储占有空间大，访问一个数据I/o的时间长； 对商品信息中商品名、商品图像、商品价格等其他字段的数据的访问频率很高。
由于这两个数据的特性不同，他考虑将商品信息表分割如下。
将不频繁访问的商品的说明信息汇总在一个表中，将频繁访问的商品的基本信息汇总在一个表中。
商品列表可以使用以下sql :
SELECT p.*，r.[地理区域名称]，s.[商店名称]，s.[gxdxh]FROM [商品信息] p LEFT JOIN [地理区域] r ON p.[产地]=r.[地理区域代码]LEFT JOIN [商店
SELECT *FROM [商品说明] WHERE [商品id]？垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段。
其提高如下
1 .为了避免io的争夺，减少锁表的概率，查看详情的用户和商品信息的浏览互不影响
2 .充分发挥热门数据操作效率，商品信息操作效率不受商品描述效率低下的拖累。
为什么大的场IO效率低下：第一，由于数据量本身多，读取时间长；第二，跨页，页面是数据库的存储单位，许多检索和检索操作都是以页面为单位。 单页中的数据行越多，数据库的整体性能越好，但由于大字段占用空间大，单页中的存储行数少，I/o效率低。 第三，数据库逐行将数据加载到内存中。 这样可以缩短表中的字段长度，提高访问频率，允许内存加载更多数据，提高命中率，减少磁盘I/o，提高数据库性能。
一般来说，一个实体数据项的访问频率各不相同。 某些数据项可能是占用存储空间的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争抢并减少锁表的几率
库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个表的数据量变小，提高检索性能。
总结垂直分表：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失。
垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。
水平分库：可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。
水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。
一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。
Sharding-jdbc视频分享分库分表生产方案Sharding-jdbc视频分享