Mysql数据库分库分表
为什么使用分库分表？
传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。
1）性能
从性能方面来说，由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降。
同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
2）可用性
从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。
3）运维成本
从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在 1TB 之内，是比较合理的范围。
那么为什么不选择 NoSQL 呢？
在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的 NoSQL 的尝试越来越多。 但 NoSQL 对 SQL 的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动
什么是分库分表？
水平分库
概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
结果：
每个库的结构都一样
每个库中的数据不一样，没有交集
所有库的数据并集是全量数据
场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库的情况下。
分析：库多了，IO 和 CPU 的压力自然可以成倍缓解。
水平分表
概念：以字段为依据，按照一定策略（hash、range 等），讲一个表中的数据拆分到多个表中。
结果：
每个表的结构都一样。
每个表的数据不一样，没有交集，所有表的并集是全量数据。
场景：系统绝对并发量没有上来，只是单表的数据量太多，影响了 SQL 效率，加重了 CPU 负担，以至于成为瓶颈，可以考虑水平分表。
分析：单表的数据量少了，单次执行 SQL 执行效率高了，自然减轻了 CPU 的负担。
垂直分库
概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中
结果：
每个库的结构都不一样。
每个库的数据也不一样，没有交集。
所有库的并集是全量数据。
场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块的情况下。
分析：到这一步，基本上就可以服务化了。例如：随着业务的发展，一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再者，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。
垂直分表
概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表中（主表和扩展表）。
结果：
每个表的结构不一样。
每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据。
所有表的并集是全量数据。
场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大，以至于数据库缓存的数据行减少，查询时回去读磁盘数据产生大量随机读 IO，产生 IO 瓶颈
分析：
可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能经常会查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表，这样更多的热点数据就能被缓存下来，进而减少了随机读 IO。拆了之后，要想获取全部数据就需要关联两个表来取数据。但记住千万别用 Join，因为 Join 不仅会增加 CPU 负担并且会将两个表耦合在一起（必须在一个数据库实例上）。关联数据应该在 Service 层进行，分别获取主表和扩展表的数据，然后用关联字段关联得到全部数据。
什么时候考虑分库分表
能不分就不分
并不是所有表都需要切分，主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”，避免“过度设计”和“过早优化”。
分库分表之前，先尽力做力所能及的优化：升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后，在考虑分库分表。
数据量过大，正常运维影响业务访问
这里的运维是指：
对数据库备份，如果单表太大，备份时需要大量的磁盘 IO 和网络 IO。
对一个很大的表做 DDL，MySQL会锁住整个表，这个时间会很长，这段时间业务不能访问此表，影响很大。
大表经常访问和更新，就更有可能出现锁等待。
随着业务发展，需要对某些字段垂直拆分
这里就不举例了，在实际业务中都可能会碰到，有些不经常访问或者更新频率低的字段应该从大表中分离出去。
数据量快速增长
随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。
分库分表带来的问题
事务一致性问题
①分布式事务
当更新内容同时存在于不同库找那个，不可避免会带来跨库事务问题。跨分片事务也是分布式事务，没有简单的方案，一般可使用“XA 协议”和“两阶段提交”处理。
分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间，导致事务在访问共享资源时发生冲突或死锁的概率增高。
随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平扩展的枷锁。
②最终一致性
对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。
与事务在执行中发生错误立刻回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等。
跨节点关联查询 Join 问题
切分之前，系统中很多列表和详情表的数据可以通过 Join 来完成，但是切分之后，数据可能分布在不同的节点上，此时 Join 带来的问题就比较麻烦了，考虑到性能，尽量避免使用 Join 查询。
解决的一些方法：
①全局表
全局表，也可看做“数据字典表”，就是系统中所有模块都可能依赖的一些表，为了避免库 Join 查询，可以将这类表在每个数据库中都保存一份。这些数据通常很少修改，所以不必担心一致性的问题。
②字段冗余
一种典型的反范式设计，利用空间换时间，为了性能而避免 Join 查询。
例如，订单表在保存 userId 的时候，也将 userName 也冗余的保存一份，这样查询订单详情顺表就可以查到用户名 userName，就不用查询买家 user 表了。
但这种方法适用场景也有限，比较适用依赖字段比较少的情况，而冗余字段的一致性也较难保证。
③数据组装
在系统 Service 业务层面，分两次查询，第一次查询的结果集找出关联的数据 id，然后根据 id 发起器二次请求得到关联数据，最后将获得的结果进行字段组装。这是比较常用的方法。
④ER 分片
分片键的选择？
分库分表后，分片键的选择非常重要。一般来说是这样的：
信息表，使用 id 进行分片。例如说，文章、商品信息等等。
业务表，使用 user_id 进行分片。例如说，订单表、支付表等等。
日志表，使用 create_time 进行分片。例如说，访问日志、登陆日志等等。
分片算法的选择？
选择好分片键之后，还需要考虑分片算法。一般来说，有如下两种：
取余分片算法。例如说，有四个库，那么 user_id 为 10 时，分到第 10 % 4 = 2 个库。
当然，如果分片键是字符串，则需要先进行 hash 的方式，转换成整形，这样才可以取余。
当然，如果分片键是整数，也可以使用 hash 的方式。
范围算法。
例如说，时间范围。
上述两种算法，各有优缺点。
对于取余来说：
好处，可以平均分配每个库的数据量和请求压力。
坏处，在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表。
对于 range 来说：
好处，扩容的时候很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了。
缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。
分库分表中间件
1）Cobar
阿里 b2b 团队开发和开源的，属于 Proxy 层方案。
早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
2）MyCAT
基于 Cobar 改造的，属于 Proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 Sharding Sphere 来说，年轻一些，经历的锤炼少一些。
3）Atlas
360 开源的，属于 Proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。
4）TDDL
淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。
5）Sharding Sphere
Sharding Sphere ，可能是目前最好的开源的分库分表解决方案，目前已经进入 Apache 孵化。