-
什么是分库分表
1分库：分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库
2垂直分表：将一个表中的数据按照每一列（字段）的访问频率或者字段长度的不同拆分到不同的表中。
3水平分表：将一个表中的数据根据每一行的某种条件水平切分，一般有根据数值范围和根据数值取模的两种方式，切分的数据表一般放在不同的数据库来分别存放。可以使数据库获得足够的硬件资源。
- 分库分表的优点
1分库可以解决业务之间的耦合问题，对不同的业务产生的数据分级管理、维护、监控、扩展。同时也能解决单机硬件资源的瓶颈。
2垂直分表的优点一个是避免跨页的问题，因为数据库的底层是通过数据页来存储的。一条数据的字段数过多或字段长度过长会导致跨页的问题，影响性能。第二个是数据库是以行为单位加载数据到内存的，而一次加载的内存大小又是一定的，所以将字段拆分开来可以使一行数据的内存占用量变小，从而一次加载更多的数据到内存，减少 磁盘IO的次数。由于将字段按照访问频率分，也可以使内存中加载的大部分都是高频访问的字段。增加了访问的命中率。
3水平分表的优点是单表数据量太大的时候会增加磁盘IO的次数，增加查找数据的时间。水平分表后，由于数据表的减小，用不同的服务器分担数据查找的压力。
- 分库分表造成的问题
1连接查询问题（业务垂直切分）：分库之后业务相同的数据会放在一个数据库，但是如果你有跨业务的需求，比如在订单表中会关联用户的信息（通常是通过用户id关联），这个时候你就需要在多个数据库分开查询，而不能通过关联查询的手段一次性查出所有的数据。导致了编码难度提高，因为查询了多次，性能也会有一定的损耗。
2.事务问题（水平切分和业务垂直切分）：数据在一个数据库中可以非常方便的进行事务的管理，但是只要将数据分散到不同的数据库，事务的管理将变得不是那么容易。需要使用分布式事务，会付出高昂的性能代价，自己去控制事务会带来额外的编程负担。
3.数据管理和数据运算问题（水平切分）：举个例子，将用户表按照规则分散到不同的表中。如果有一个要按照用户注册时间排序取前100名的需求，你需要对每个用户表按照注册时间排序分别取前100名的数据，再对去除的数据进行分析合并。这种数据运算不适合分表。
4.全局主键避重问题（水平切分）：分库分表之后由于数据位于不同的服务器，之前的主键的自动增长的策略将不再有效。
5.数据迁移、扩容问题（水平切分）：水平分表后随着数据量的不断增大，需要创建更多的分表来存储数据，需要更多的服务器来进行数据的扩容。
- 解决分库分表的问题
1.对于连接查询的问题有几种解决方案
- 增加冗余字段，比如在订单表中增加username的字段。在生成订单的时候就不需要连接用户表进行查询。但是这样会造成另外一个问题，比如你在修改用户名的时候是否需要对订单表中的用户名进行修改（用户名可以使其他的字段）。
- 数据组装，在第一次查询的结果集中找出关联id,在以id为请求条件向另外的数据库发起第二次请求（可能有多次请求），最后把所有的结果集按照条件组合起来。缺点是要发多次请求占用网络带宽。组合数据要占用CPU时间。
2.对于事务问题
- 分布式事务框架，由框架自动控制。优点是方便。缺点是耗费大量的服务器资源。
- 在应用程序中自己去控制事务，优点是灵活不太耗费资源，缺点是增加了编程的复杂性。
3.对于数据管理和运算的问题
- 无解决方法，有大量这样的计算需求的可以考虑不用水平切分。
4.对于全局主键避重的问题
- 生成UUID（一个不会重复的序列字符串），优点是生成本地生成，没有网络耗时。缺点是UUID非常长（32个16进制数字），会占用大量的存储空间。会占用大量的存储空间；另外，作为主键建立索引和基于索引进行查询时都会存在性能问题，在InnoDB下，UUID的无序性会引起数据位置频繁变动，导致分页。
- Snowflake分布式自增ID算法
- Leaf——美团点评分布式ID生成方案
5.数据迁移可和扩容的问题
- 如果采用数值范围分片，只需要添加节点就可以进行扩容了，不需要对数据进行迁移，但是如果采用数值取模分片的方式，就要将旧数据和新数据重新散列到不同的数据库。