为什么要分表？
当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，有可能会死在那儿了。
分表的目的就在于此，减小数据库的负担，缩短查询时间。
日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。
分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应的数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。
mysql执行一个sql的过程如下：
1、接收到sql;
2、把sql放到排队队列中;
3、执行sql;
4、返回执行结果。
如果数据太多，一次执行的时间太长，等待的时间就越长，这也是我们为什么要分表的原因。
分表方案
集群
虽然它不是实际意义上的分表，但是它启到了分表的作用，做集群的意义是什么呢？
为一个数据库减轻负担，说白了就是减少sql排队队列中的sql的数量。
举个例子：有10个sql请求，如果放在一个数据库服务器的排队队列中，他要等很长时间，如果把这10个sql请求，分配到5个数据库服务器的排队队列中，一个数据库服务器的队列中只有2个，这样等待时间是不是大大的缩短了呢？
这已经很明显了。所以我把它列到了分表的范围以内，我做过一些mysql的集群：
linux mysql proxy 的安装、配置，以及读写分离
mysql replication 互为主从的安装及配置，以及数据同步
优点：扩展性好，没有多个分表后的复杂操作。
缺点：单个表的数据量还是没有变，一次操作所花的时间还是那么多，硬件开销大。
分表
分表分库是将数据拆分成不同的存储单元。
从拆分的角度上，可以分为垂直分片和水平分片。
垂直分片(纵向分片)
垂直分片就是按字段拆分成多个表，垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对业务需求快速变化的。而且，他也无法真正的解决单点数据库的性能瓶颈。
垂直分片可以缓解数据量和访问量带来的问题，但无法根治。
如果垂直分片之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。
水平分片(横向分片)
相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段(或某几个字段)，根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。
比如：一个数据库有3000W用户记录，处理速度比较慢，这时可以把3000W分成五份，每份都是600W，分别放在不同的机器上。
水平分片就是预先估计会出现大数据量并且访问频繁的表，将其分为若干个表。
比如：论坛里面发表帖子的表，时间长了这张表肯定很大，就事先建好100个这样的表，table_00,table_01,table_02……….table_98,table_99.然后根据用户的ID来判断这个用户的聊天信息放到哪张表里面，可以用求余的方式来获得。
常用的分片策略有：
| 策略 | 优点 | 缺点 | demo |
|---|---|---|---|
| 取余\取模 | 均匀存放数据 | 扩容非常麻烦 | id % 2 |
| 按照范围分片 | 比较好扩容 | 数据分布不够均匀 | 月 |
| 按照枚举值分片 | 比较好扩容 | 数据分布不够均匀 | 按地区分片 |
| 按照目标字段前缀指定进行分区 | 自定义业务规则分片 | 数据分布不够均匀 |
水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。
一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案；
在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。
若数据量极大，且持续增长，再考虑水平分库水平分表方案。
实际应用中
需要把垂直分表和水平分表结合起来使用，如果一个数据库有3000w用户的话，可以先考虑垂直拆，拆完之后在进行水平拆分。
就是先将其他字段拆分到user_info表中，用户主表user只留下用户id，密码，用户名等关键字段。
之后在进行水平拆分，将用户和用户信息表分为多个同样结构的表。
Sharding-JDBC提供的几种分表策略
行表达式分片策略
提供对SQL语句中的=和IN的分片操作支持，只支持单分片键。
- 可以通过简单的配置使用，从而避免繁琐的Java代码开发，如: t_user_$->{u_id % 8} 表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。
标准分片策略
提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。
- PreciseShardingAlgorithm是必选的，用于处理=和IN的分片。
- RangeShardingAlgorithm是可选的，用于处理BETWEEN AND, >, <, >=, <=分片。
复合分片策略
提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。
- ComplexShardingStrategy支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。
分表存储数据是如何运作的？
简单的MySQL主从复制
MySQL的主从复制解决了数据库的读写分离，并很好的提升了读的性能，其图如下：
其主从复制的过程如下图所示：
主从复制也带来其他一系列性能瓶颈问题：
- 写入无法扩展
- 写入无法缓存
- 复制延时
- 锁表率上升
- 表变大，缓存率下降
那问题产生总得解决的，这就产生下面的优化方案，一起来看看。
MySQL垂直分区
如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案。
而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。经过垂直分区后的数据库架构图如下：
尽管业务之间已经足够独立了，但是有些业务之间或多或少总会有点联系，如用户，基本上都会和每个业务相关联，况且这种分区方式，也不能解决单张表数据量暴涨的问题，因此为何不试试水平分割呢？
MySQL水平分片（Sharding）
将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下：
如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示：
分表分库基本概念
一主多备
在实际的应用中，绝大部分情况都是读远大于写。Mysql提供了读写分离的机制，所有的写操作都必须对应到Master，读操作可以在 Master和Slave机器上进行，Slave与Master的结构完全一样，一个Master可以有多个Slave,甚至Slave下还可以挂 Slave,通过此方式可以有效的提高DB集群的 QPS。
所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
单库单表
单库单表是最常见的数据库设计，例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。
单库多表
随着用户数量的增加，user表的数据量会越来越大，当数据量达到一定程度的时候对user表的查询会渐渐的变慢，从而影响整个DB的性能。如果使用mysql, 还有一个更严重的问题是，当需要添加一列的时候，mysql会锁表，期间所有的读写操作只能等待。
可以通过某种方式将user进行水平的切分，产生两个表结构完全一样的user_0000,user_0001等表，user_0000 + user_0001 + …的数据刚好是一份完整的数据。
多库多表
随着数据量增加也许单台DB的存储空间不够，随着查询量的增加单台数据库服务器已经没办法支撑。这个时候可以再对数据库进行水平区分。
分库分表规则
设计表的时候需要确定此表按照什么样的规则进行分库分表。例如，当有新用户时，程序得确定将此用户信息添加到哪个表中；同理，当登录的时候我们得通过用户的账号找到数据库中对应的记录，所有的这些都需要按照某一规则进行。
路由
通过分库分表规则查找到对应的表和库的过程。如分库分表的规则是user_id mod 4的方式，当用户新注册了一个账号，账号id的123,我们可以通过id mod 4的方式确定此账号应该保存到User_0003表中。当用户123登录的时候，我们通过123 mod 4后确定记录在User_0003中。
分表分库产生的问题，及注意事项
1. 分库分表维度的问题
假如用户购买了商品，需要将交易记录保存取来，如果按照用户的纬度分表，则每个用户的交易记录都保存在同一表中，所以很快很方便的查找到某用户的购买情况，但是某商品被购买的情况则很有可能分布在多张表中，查找起来比较麻烦。反之，按照商品维度分表，可以很方便的查找到此商品的购买情况，但要查找到买方的交易记录比较麻烦。
常见的解决方式有：
- 通过扫表的方式解决，此方法基本不可能，效率太低了。
- 记录两份数据，一份按照用户纬度分表，一份按照商品维度分表。
- 通过搜索引擎解决，但如果实时性要求很高，又得关系到实时搜索。
2. 事务一致性问题
原本单机数据库有很好的事务机制能够帮我们保证数据一致性。但是分库分表后，由于数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。 两阶段三阶段（seata）
3. 跨节点关联查询问题
在没有分库时，我们可以进行很容易的进行跨表的关联查询。但是在分库后，表被分散到了不同的数据库，就无法进行关联查询了。这时就需要将关联查询拆分成多次查询，然后将获得的结果进行拼装。
4. 跨节点分页、排序函数
跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。这时非常容易出现内存崩溃的问题。
5. 主键避重问题
在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。(uuid、 雪花算法、redis、没有业务含义)
6. 公共表处理
实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。这一类表一般就需要在每个数据库中都保存一份，并且所有对公共表的操作都要分发到所有的分库去执行。
7. 运维工作量
面对散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作都变得非常繁重。对于每一次数据读写操作，他们都需要知道要往哪个具体的数据库的分表去操作，这也是其中重要的挑战之一。
什么时候需要分库分表？
对于分库分表的观点，需要结合实际需求，不宜过度设计，在项目开始不采用分库与分表设计，只是随着业务的增长，在无法继续优化的情况下，再考虑分库与分表提高系统的性能。
在阿里巴巴公布的开发手册中，建议MySQL单表记录如果达到500W这个级别，或者单表容量达到2GB，一般就建议进行分库分表。
对此，阿里巴巴《Java 开发手册》补充到：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。那么，你觉得这个数值多少才合适呢？我的建议是，根据自身的机器的情况综合评估，如果心里没有标准，那么暂时以 500 万?作为一个统一的标准，相对而言算是一个比较折中的数值。
另外，在设计分库分表方案时，要尽量兼顾业务场景和数据分布。在支持业务场景的前提下，尽量保证数据能够分得更均匀。
最后，一旦用到了分库分表，就会表现为对数据查询业务的灵活性有一定的影响，例如如果按userId进行分片，那按age来进行查询，就必然会增加很多麻烦。
如果再要进行排序、分页、聚合等操作，很容易就扛不住了。
这时候，都要尽量在分库分表的同时，再补充设计一个降级方案，例如将数据转存一份到ES，ES可以实现更灵活的大数据聚合查询。
常见的分库分表组件
shardingsphere 官网地址： https://shardingsphere.apache.org/document/current/cn/overview/
Sharding-JDBC是当当网研发的开源分布式数据库中间件，他是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
mycat 官网地址： http://www.mycat.org.cn/
基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得MYCAT一开始就拥有一个很好的起点，
DBLE 官网地址：https://opensource.actionsky.com/
该网站包含几个重要产品。其中分布式中间件可以认为是MyCAT的一个增强版，专注于MySQL的集群化管理。另外还有数据传输组件和分布式事务框架组件可供选择。
业务层改造：
基于代理层方式：Mycat、Sharding-Proxy、MySQL Proxy
基于应用层方式：Sharding-jdbc