mysql分库分表

分库分表的类型和特点

从维度来说分成两种，一种是垂直，一种是水平。
垂直切分：基于表或字段划分，表结构不同。我们有单库的分表，也有多库的分库。
水平切分：基于数据划分，表结构相同，数据不同，也有同库的水平切分和多库的
切分。
2.1 垂直切分
垂直分表有两种，一种是单库的，一种是多库的。
1 2.1.1 单库垂直 分表
单库分表，比如：商户信息表，拆分成基本信息表，联系方式表，结算信息表，附
件表等等。
2 2.1.2 多库垂直 分表
多库垂直分表就是把原来存储在一个库的不同的表，拆分到不同的数据库。
比如：消费金融核心系统数据库，有很多客户相关的表，这些客户相关的表，全部
单独存放到客户的数据库里面。合同，放款，风控相关的业务表也是一样的

当我们对原来的一张表做了分库的处理，如果某些业务系统的数据还是有一个非常
快的增长速度，比如说还款数据库的还款历史表，数据量达到了几个亿，这个时候硬件
限制导致的性能问题还是会出现，所以从这个角度来说垂直切分并没有从根本上解决单
库单表数据量过大的问题。在这个时候，我们还需要对我们的数据做一个水平的切分。

2.2 水平切分
当我们的客户表数量已经到达数千万甚至上亿的时候，单表的存储容量和查询效率
都会出现问题，我们需要进一步对单张表的数据进行水平切分。水平切分的每个数据库
的表结构都是一样的，只是存储的数据不一样，比如每个库存储 1000 万的数据。
水平切分也可以分成两种，一种是单库的，一种是多库的。
1 2.2.1 单库 水平分表
银行的交易流水表，所有进出的交易都需要登记这张表，因为绝大部分时候客户都
是查询当天的交易和一个月以内的交易数据，所以我们根据使用频率把这张表拆分成三
张表：
当天表：只存储当天的数据。
当月表：在夜间运行一个定时任务，前一天的数据，全部迁移到当月表。用的
是 insert into select，然后 delete。
历史表：同样是通过定时任务，把登记时间超过 30 天的数据，迁移到 history
历史表（历史表的数据非常大，我们按照月度，每个月建立分区）。
费用表：
消费金融公司跟线下商户合作，给客户办理了贷款以后，消费金融公司要给商户返
费用，或者叫提成，每天都会产生很多的费用的数据。为了方便管理，我们每个月建立
一张费用表
但是注意，跟分区一样，这种方式虽然可以一定程度解决单表查询性能的问题，但
是并不能解决单机存储瓶颈的问题。

2.2.2 多库 水平分表
另一种是多库的水平分表。比如客户表，我们拆分到多个库存储，表结构是完全一
样的。
一般我们说的分库分表都是跨库的分表。
既然分库分表能够帮助我们解决性能的问题，那我们是不是马上动手去做，甚至在
项目设计的时候就先给它分几个库呢？先冷静一下，我们来看一下分库分表会带来哪些
问题，也就是我们前面说的分库分表之后带来的复杂性。

2.3 多 案 分库分表带来的问题
1 2.3.1 跨库关联查询
比如查询在合同信息的时候要关联客户数据，由于是合同数据和客户数据是在不同
的数据库，那么我们肯定不能直接使用 join 的这种方式去做关联查询。
我们有几种主要的解决方案：
1、字段冗余
比如我们查询合同库的合同表的时候需要关联客户库的客户表，我们可以直接把一
些经常关联查询的客户字段放到合同表，通过这种方式避免跨库关联查询的问题。
2、数据同步：比如商户系统要查询产品系统的产品表，我们干脆在商户系统创建一
张产品表，通过 ETL 或者其他方式定时同步产品数据。
3、全局表（广播表） 比如行名行号信息被很多业务系统用到，如果我们放在核心
系统，每个系统都要去关联查询，这个时候我们可以在所有的数据库都存储相同的基础
数据。
4、ER 表（绑定表）
我们有些表的数据是存在逻辑的主外键关系的，比如订单表 order_info，存的是汇
总的商品数，商品金额；订单明细表 order_detail，是每个商品的价格，个数等等。或者
叫做从属关系，父表和子表的关系。他们之间会经常有关联查询的操作，如果父表的数
据和子表的数据分别存储在不同的数据库，跨库关联查询也比较麻烦。所以我们能不能
把父表和数据和从属于父表的数据落到一个节点上呢？
比如 order_id=1001 的数据在 node1，它所有的明细数据也放到 node1；
order_id=1002 的数据在 node2，它所有的明细数据都放到 node2，这样在关联查询的
时候依然是在一个数据库。
上面的思路都是通过合理的数据分布避免跨库关联查询，实际上在我们的业务中，
也是尽量不要用跨库关联查询，如果出现了这种情况，就要分析一下业务或者数据拆分
是不是合理。如果还是出现了需要跨库关联的情况，那我们就只能用最后一种办法。

5、系统层组装
在不同的数据库节点把符合条件数据的数据查询出来，然后重新组装，返回给客户
端。