移动互联网时代，每天产生海量的数量，比如：
-
用户表
-
订单表
-
交易流水表
以支付宝用户为例，8亿；微信用户更是10亿。订单表更夸张，比如美团外卖，每天都是几千万的订单。淘宝的历史订单总量应该百亿，甚至千亿级别，这些海量数据远不是一张表能Hold住的。
以下内容是我在工作过程中对分库分表的总结，分享给大家。
一．为什么要分库分表
假如一个创业公司，刚开始时，注册商户5k，活跃商户1k，商户的每天的交易量1w,每天单表数据量就1w，高峰时的TPS为10.这种情况一般单库单表可以搞定。
但是随着注册商户和活跃商户达到数十万，每天的交易量达到百万级别，高峰时TPS上千时，单库单表性能就存在很大的问题了。
二．什么是分库分表
分库分表的基本思想就是把单库单表的数据按照一定的规则放到不同的库和表中，从而缓解单库单表的性能问题。
1. 分表
当单表数据量太大，会极大地影响sql的执行性能，sql会跑的很慢，响应时间会很长，影响用户体验。
分表就是将一个表的数据按照一定的规则存放到不同的表中，当查数据时，只要根据规则路由到某个表。根据经验，mysql单表数据量达到1000w-2000w，oracle单表数据量达到1亿条左右。当然这还得根据具体的业务来分析。
2.分库
单库而言，最大的并发可能就2000左右，但是一个健壮的单库来说最好的并发保持在1000左右。单数据库增大或者并发增加的时候，可以将一个库的数据拆分到多个库中。
分库分表前
分库分表后
并发情况
mysql单机，支撑不了高并发
mysql集群，并发加倍
磁盘情况
磁盘容量很快撑满
拆分多个表，磁盘使用率降低
sql执行速度
数据量越来越大，sql执行越来越慢
单表数据量少，sql执行速度快
三．数据的切分类型
数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分。
1.垂直切分
垂直切分常见有垂直分库和垂直分表两种。
垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。按业务分类进行独立划分，每个不同的业务使用单独的一个数据库。如图：
垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。
优点：
1.解决业务系统层面的耦合，业务清晰
2.与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
3.高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点：
1.部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
2.分布式事务处理复杂
3.依然存在单表数据量过大的问题（需要水平切分）
2.水平切分
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。如图所示：
摘自网络
库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。
优点：
1.不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
2.应用端改造较小，不需要拆分业务模块
缺点：
1.跨分片的事务一致性难以保证
2.跨库的join关联查询性能较差
3.数据多次扩展难度和维护量极大
四．数据的分片规则
说到数据的切分，必定要说到的数据的分片规则。几种典型的数据分片规则为：
1. 数值的范围
按照时间范围或某个字段值的区间（比如userId，主键）来划分。例如：按日期将不同月甚至是日的数据分散到不同的库中；将userId为19999的记录分到第一个库，1000020000的分到第二个库，以此类推。某种意义上，某些系统中使用的"冷热数据分离"，将一些使用较少的历史数据迁移到其他库中，业务功能上只提供热点数据的查询，也是类似的实践。
优点
：
1.单表大小可控
2.天然便于水平扩展，后期如果想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片的数据进行迁移
3.使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题。
缺点：
热点数据成为性能瓶颈。连续分片可能存在数据热点，例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询。
2. 根据数值的取模
一般采用hash取模mod的切分方式，例如：将 Customer 表根据 cusno 字段切分到4个库中，余数为0的放到第一个库，余数为1的放到第二个库，以此类推。这样同一个用户的数据会分散到同一个库中，如果查询条件带有cusno字段，则可明确定位到相应库去查询。
优点
：
数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈
缺点
：
1.后期分片集群扩容时，需要迁移旧的数据（使用一致性hash算法能较好的避免这个问题）
2.容易面临跨分片查询的复杂问题。比如上例中，如果频繁用到的查询条件中不带cusno时，将会导致无法定位数据库，从而需要同时向4个库发起查询，再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。
五．分库分表实现方案
目前分库分表的实现方案大概有几种，网上的资料也比较多，内容也很详细，这里就不在多做介绍了。
1）简单实现
目前采用mybatis的拦截器来实现，功能简单，容易实现。缺点就是功能比较少
2）Shading-jdbc
shardingsphere.apache.org/document/le…这个链接是Shading-jdbc的官网，大家感兴趣的可以去了解一下。
3）Mycat
mycat.org.cn/这个链接是mycat的官网，大家感兴趣的可以去了解一下。
4）DRDS
drds阿里商业版的分布式关系型数据库服务，花钱就可以了，使用和mysql差不多。
www.aliyun.com/product/drd…这个链接是DRDS的产品介绍。
最后做个总结：
sharding-jdbc：当当开源的，属于client层方案。确实之前用的还比较多一些，因为SQL语法支持也比较多，没有太多限制，而且目前推出到了2.0版本，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。sharding-jdbc这种client层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从2017年一直到现在，是不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。
mycat：基于cobar改造的，属于proxy层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于sharding jdbc来说，年轻一些，经历的锤炼少一些。mycat这种proxy层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。
通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；
六．分库分表带来的问题
分库分表能有效的环节单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。
1. 事务一致性问题
当更新的内容在不同库中，不可避免会带来跨库的事务问题。跨库的事务问题也是分布式事务。对数据要求强一致性的，可以采用两阶段提交和三阶段提交。对那些性能要求高的，对数据要求不高的。可采用事务补偿的方式，比如消息队列，本地消息表等。
2. 跨库关联查询问题
切分之前，系统中很多列表和详情页所需的数据可以通过sql join来完成。而切分之后，数据可能分布在不同的节点上，此时join带来的问题就比较麻烦了，考虑到性能，尽量避免使用join查询。
解决这个问题的有以下方法：
1）全局表
全局表，也可看做是"数据字典表"，就是系统中所有模块都可能依赖的一些表，为了避免跨库join查询，可以将这类表在每个数据库中都保存一份。这些数据通常很少会进行修改，所以也不担心一致性的问题。
2）字段冗余
一种典型的反范式设计，利用空间换时间，为了性能而避免join查询。例如：订单表保存userId时候，也将userName冗余保存一份，这样查询当担详情时就不需要再去查询"user表"了。
但这种方法适用场景也有限，比较适用于依赖字段比较少的情况。而冗余字段的数据一致性也较难保证，就像上面订单表的例子，买家修改了userName后，是否需要在历史订单中同步更新呢？这也要结合实际业务场景进行考虑。
3）数据组装
查询时分两次查询，第一次查询出主表的结果集中找出关联字段，然后根据关联字段发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。
这个是比较常用到的
。
4）ER分片
关系型数据库中，如果可以先确定表之间的关联关系，并将那些存在关联关系的表记录存放在同一个分片上，那么就能较好的避免跨分片join问题。在1:1或1:n的情况下，通常按照主表的ID主键切分。如下图所示：
-
跨节点分页、非分片键查询问题
分页
：跨库分页会出现全库全表查询，同时返回的数据也是随机的。
解决办法
：分页操作时必须显示加上排序条件才能保证结果的正确性。
非分片键查询问题
：查询时，不带非分片键查询，会导致扫描全库全表，性能很差，甚至会导致系统崩溃。查询时尽量带上分片键。
4. 全局主键避重问题
有以下几种解决方案：
1.简单实现：ip+时间戳+随机数
3.UidGenerator–百度开源分布式id生成器
UidGenerator使用Java实现，基于Snowflake算法的唯一ID生成器。 gitee地址：gitee.com/mirrors/Uid…
4：Leaf–美团点评分布式ID生成器
Leaf 使用Java实现，提供两种生成ID的方式（Snowflake模式和号段模式），可以通过修改配置选择ID的生成方式。 GitHub地址：github.com/Meituan-Dia… 官方文档地址：tech.meituan.com/2017/04/21/…
七．什么时候考虑切分
前面简单提到当数据量达到多少时，考虑切分。那下面具体讲述一下什么时候需要考虑做数据切分。
1、能不切分尽量不要切分
并不是所有表都需要进行切分，主要还是看表数据的增长速度。切分后会引用新的技术，提升系统的技术复杂度和学习成本，人力成本。
如果数据量不是很大，不用轻易使用分库分表这个大招，避免"过度设计"和"过早优化"。分库分表之前，不要为分而分，先尽力去做力所能及的事情，例如：升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。
2、数据量过大，影响业务访问
1）对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO。将库表进行拆分，备份时间短，每个库和表所需的磁盘io和网络io分散到其他机器上。
2）对一个大表进行DDL修改时，MySQL会锁住全表，sql执行时间会很长，这段时间业务不能访问此表，影响很大。将数据表拆分，总量减少，有助于降低这个风险。
3）大表会经常访问与更新，就更有可能出现锁等待。将数据切分，用空间换时间，变相降低访问压力。
3、随着业务发展，需要对某些字段垂直拆分
举个例子，假如项目一开始设计的用户表如下：
uid bigint 客户id
username varchar 客户名称
last_login_time datetime 最近登录时间
在项目初始阶段，这种设计是满足简单的业务需求的，也方便快速迭代开发。而当业务快速发展时，用户量从10w激增到10亿，用户非常的活跃，每次登录会更新 last_login_name 字段，使得 user 表被不断update，压力很大。而其他字段：uid, username是不变的或很少更新的，此时在业务角度，就要将 last_login_time 拆分出去，新建一个 user_time 表。
4、数据量快速增长
随着业务的快速发展，单表中的数据量会持续增长，每天单表的数据量从几十万到几百万。当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。此时一定要选择合适的切分规则，根据业务的类型，提前预估好数据容量。
5、安全性和可用性
安全性：利用分库分表，每个业务的数据量存放在不同的机器上。当数据丢失也不会全部丢失。可用性：利用水平切分，当一个数据库出现问题时，不会影响到100%的用户，每个库只承担业务的一部分数据，这样整体的可用性就能提高。不能因为一个业务把数据库搞挂而牵连到其他业务。
八.总结
本文简单介绍了一下为什么要分库分表，实现方案是什么，和分库分表带来的问题。分库分表的内容很多，这里就不做详细的描述。如果大家感兴趣，可以查看官网的文档，感谢阅读。
