MySQL-如何分库分表？一看就懂

Posted 2023-04-06 请叫我黄同学

一、为什么要分库分表

如果一个网站业务快速发展，那这个网站流量也会增加，数据的压力也会随之而来，比如电商系统来说双十一大促对订单数据压力很大，Tps十几万并发量，如果传统的架构（一主多从），主库容量肯定无法满足这么高的Tps，业务越来越大，单表数据超出了数据库支持的容量，持久化磁盘IO,传统的数据库性能瓶颈，产品经理业务·必须做，改变程序，数据库刀子切分优化。数据库连接数不够需要分库，表的数据量大，优化后查询性能还是很低，需要分。

二、什么是分库分表

分库分表方案是对关系型数据库数据存储和访问机制的一种补充。
分库：将一个库的数据拆分到多个相同的库中，访问的时候访问一个库
分表：把一个表的数据放到多个表中，操作对应的某个表就行

三、分库分表的几种方式

1.垂直拆分

(1) 数据库垂直拆分
根据业务拆分，如图，电商系统，拆分成订单库，会员库，商品库

(2)表垂直拆分

根据业务去拆分表，如图，把user表拆分成user_base表和user_info表，use_base负责存储登录，user_info负责存储基本用户信息

垂直拆分特点
1.每个库（表）的结构都不一样
2.每个库（表）的数据至少一列一样
3.每个库（表）的并集是全量数据

垂直拆分优缺点

优点：
1.拆分后业务清晰（专库专用按业务拆分）
2.数据维护简单，按业务不同，业务放到不同机器上

缺点:
1.如果单表的数据量，写读压力大
2.受某种业务决定，或者被限制，也就是说一个业务往往会影响到数据库的瓶颈（性能问题，如双十一抢购）
3.部分业务无法关联join，只能通过java程序接口去调用，提高了开发复杂度

2. 水平拆分

(1) 数据库水平拆分

如图，按会员库拆分，拆分成会员1库，会员2库，以userId拆分，userId尾号0-5为1库
6-9为2库，还有其他方式，进行取模，偶数放到1库，奇数放到2库

(2) 表水平拆分

如图把users表拆分成users1表和users2表，以userId拆分，进行取模，偶数放到users1表，奇数放到users2表

水平拆分的其他方式

1. range来分,每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了,优点：扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了 缺点：大部分的 请求，都是访问最新的数据。实际生产用range，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据
2. hash分发,优点：可以平均分配每个库的数据量和请求压力 缺点：扩容起来比较麻烦，会有一个数据迁移的这么一个过程

水平拆分特点
1.每个库（表）的结构都一样
2.每个库（表）的数据都不一样
3.每个库（表）的并集是全量数据

水平拆分优缺点

优点：
1.单库/单表的数据保持在一定量（减少），有助于性能提高
2.提高了系统的稳定性和负载能力
3.拆分表的结构相同，程序改造较少。

缺点:
1.数据的扩容很有难度维护量大
2.拆分规则很难抽象出来
3.分片事务的一致性问题部分业务无法关联join，只能通过java程序接口去调用

四、分库分表带来的问题

1. 分布式事务
2. 跨库join查询
3. 分布式全局唯一id
4. 开发成本 对程序员要求高

五、分库分表技术如何选型

分库分表的开源框架
jdbc 直连层：shardingsphere、tddl
proxy 代理层：mycat，mysql-proxy（360）

jdbc直连层

jdbc直连层又叫jdbc应用层,是因为所有分片规则，所有分片逻辑，包括处理分布式事务
所有这些问题它都是在应用层，所有项目都是由war包构成的，所有分片都写成了jar包，放到了war包里面，java需要虚拟机去运行的，虚拟机运行的时候就会把war包里面的字节文件进行classLoder加载到jvm内存中，所有分片逻辑都是基于内存方进行操作的

proxy代理层

如图,proxy代理层，所有分片规则，所有分片逻辑，包括处理分布式事务都在mycat写好了,所有分片逻辑都是基于mycat方进行操作

jdbc直连层和proxy代理层优缺点

• jdbc直连层性能高，只支持java语言，支持跨数据库
• proxy代理层开发成本低，支持跨语言，不支持跨数据库

一看就懂的贪心算法

如何理解贪心算法

我们先看一个例子

假设有一个可以容纳100kg物品的背包，背包可以装各种物品，我们有以下五种豆子，每种豆子的重量和总价值各不相同。为了让背包中所装物品的总价值最大，我们如何选择在背包中装哪些豆子？每种豆子又应该装多少？

我们可以这样想，我们只需要计算出每种豆子的单价，按照价格由高到低依次来装豆子，先按单价最高的豆子装，装不满的话，再装价格相对较低的豆子，直到装满为止。

这个问题的解决思路就是用了贪心算法的思想，我们先来看以下贪心算法解决问题的步骤：

第一步：套用贪心算法的问题模型：针对一组数据，事先定义了限制值和期望值，希望从中选择几个数据，在满足限制的情况下，期望值最大。针对刚才的例子，限制值就是装载背包中的豆子不能超过100kg，期望值就是装在背包中的豆子的总价值。这组数据就是5种豆子，从中选出 一部分豆子，满足重量不超过100kg，并且总价值最大。

第二步：尝试用贪心算法来解决：每次选择对限制值同等贡献量的情况下，对期望值贡献最大的数据。针对刚才的例子，每次都从剩下的豆子里选择单价最高的，也就是重量相同的情况下，对价值贡献最大的豆子。

第三步：举例验证算法是否正确：在大部分情况下，举几个例子验证以下短发是否能得到最优解就可以了。

实际上，用贪心算法解决问题，并不能给出最优解。

再来看一个例子，在一个有权图中找一条从顶点S到顶点T的最短路径（路径中边的权值最小）。贪心算法的解决思路：每次都选择一条与当前顶点相连的权值最小的边，也就是对总路径长度贡献最小的边，直到找到顶点T。按照这种思路，我们求出的最短路径是S->A->E->T,路径长度是1+4+4 = 9。

但是，基于这种贪心算法，最终得到的路径并非最短路径，因为路径S->B->D->T更短，长度为6。贪心算法不能解决这个问题的主要原因是在贪心选择过程中前面的选择会影响后面的选择。如果第一步从顶点S到顶点A，那么接下来面对的顶点和边与第一步从顶点S到顶点B是完全不同的。因此，即便我们在第一步选择最优的走法，也有可能因为这一步的选择导致后面的每一步都很糟糕。

贪心算法的应用示例

1. 分糖果

我们有 m 个糖果和 n 个孩子。我们现在要把糖果分给这些孩子吃，但是糖果少，孩子（m<n），所以糖果只能分配给一部分孩子。

每个糖果的大小不等，这 m 个糖果的大小分别是 s1，s2，s3，……，sm。除此之外，每个 孩子对糖果大小的需求也是不一样的，只有糖果的大小大于等于孩子的对糖果大小的需求的 时候，孩子才得到满足。假设这 n 个孩子对糖果大小的需求分别是 g1，g2，g3，……， gn。

我的问题是，如何分配糖果，能尽可能满足最多数量的孩子？

我们可以把这个问题抽象成，从 n 个孩子中，抽取一部分孩子分配糖果，让满足的孩子的 个数（期望值）是最大的。这个问题的限制值就是糖果个数 m。

我们现在来看看如何用贪心算法来解决。对于一个孩子来说，如果小的糖果可以满足，我们 就没必要用更大的糖果，这样更大的就可以留给其他对糖果大小需求更大的孩子。另一方 面，对糖果大小需求小的孩子更容易被满足，所以，我们可以从需求小的孩子开始分配糖 果。因为满足一个需求大的孩子跟满足一个需求小的孩子，对我们期望值的贡献是一样的。

我们每次从剩下的孩子中，找出对糖果大小需求最小的，然后发给他剩下的糖果中能满足他 的最小的糖果，这样得到的分配方案，也就是满足的孩子个数最多的方案。

2. 钱币找零

这个问题在我们的日常生活中更加普遍。假设我们有 1 元、2 元、5 元、10 元、20 元、 50 元、100 元这些面额的纸币，它们的张数分别是 c1、c2、c5、c10、c20、c50、 c100。我们现在要用这些钱来支付 K 元，最少要用多少张纸币呢？

在生活中，我们肯定是先用面值最大的来支付，如果不够，就继续用更小一点面值的，以此 类推，最后剩下的用 1 元来补齐。

在贡献相同期望值（纸币数目）的情况下，我们希望多贡献点金额，这样就可以让纸币数更 少，这就是一种贪心算法的解决思路。直觉告诉我们，这种处理方法就是最好的。

3. 区间覆盖

假设我们有 n 个区间，区间的起始端点和结束端点分别是 [l1, r1]，[l2, r2]，[l3, r3]， ……，[ln, rn]。我们从这 n 个区间中选出一部分区间，这部分区间满足两两不相交（端点相 交的情况不算相交），最多能选出多少个区间呢？

这个问题的处理思路稍微不是那么好懂，不过，我建议你最好能弄懂，因为这个处理思想在 很多贪心算法问题中都有用到，比如任务调度、教师排课等等问题。 这个问题的解决思路是这样的：我们假设这 n 个区间中最左端点是 lmin，最右端点是 rmax。这个问题就相当于，我们选择几个不相交的区间，从左到右将 [lmin, rmax] 覆盖 上。我们按照起始端点从小到大的顺序对这 n 个区间排序。

我们每次选择的时候，左端点跟前面的已经覆盖的区间不重合的，右端点又尽量小的，这样 可以让剩下的未覆盖区间尽可能的大，就可以放置更多的区间。这实际上就是一种贪心的选择方法

 如何用贪心算法解决赫夫曼编码

假设有一个包含1000个字符的文件，每个字符占1B(1B = 8bit)，存储这1000个字符需要8000bit，那么有没有更加节省空间的存储方式呢？

假设通过统计分析发现，这1000个字符中只包含六种不同的字符，假设分别是a,b,c,d,e,f。而三个二进制位(bit)就可以表示8个不同的字符，因此为了减少存储空间，每个字符用三个二进制位来表示：a为000，b为001，c为010，d为011，e为100，f为101。那么，存储这1000个字符只需要3000bit，比原来存储方式节省了很多空间。还有没有更加节省空间的方式呢？

此时就需要用到赫夫曼编码了，他是一种非常有效的编码方式，广泛应用于数据压缩中，其压缩率通常为20%-90%。

霍夫曼编码不仅会考察文本中有多少个不同字符，还会考察每个字符出现的频率，根据频率 的不同，选择不同长度的编码。霍夫曼编码试图用这种不等长的编码方法，来进一步增加压 缩的效率。如何给不同频率的字符选择不同长度的编码呢？根据贪心的思想，我们可以把出 现频率比较多的字符，用稍微短一些的编码；出现频率比较少的字符，用稍微长一些的编 码.

对于等长的编码来说，我们解压缩起来很简单。比如刚才那个例子中，我们用 3 个 bit 表 示一个字符。在解压缩的时候，我们每次从文本中读取 3 位二进制码，然后翻译成对应的 字符。但是，霍夫曼编码是不等长的，每次应该读取 1 位还是 2 位、3 位等等来解压缩 呢？这个问题就导致霍夫曼编码解压缩起来比较复杂。为了避免解压缩过程中的歧义，霍夫 曼编码要求各个字符的编码之间，不会出现某个编码是另一个编码前缀的情况。

 

假设这 6 个字符出现的频率从高到低依次是 a、b、c、d、e、f。我们把它们编码下面这个 样子，任何一个字符的编码都不是另一个的前缀，在解压缩的时候，我们每次会读取尽可能 长的可解压的二进制串，所以在解压缩的时候也不会歧义。经过这种编码压缩之后，这 1000 个字符只需要 2100bits 就可以了

 

尽管霍夫曼编码的思想并不难理解，但是如何根据字符出现频率的不同，给不同的字符进行 不同长度的编码呢？这里的处理稍微有些技巧。

我们把每个字符看作一个节点，并且辅带着把频率放到优先级队列中。我们从队列中取出频 率最小的两个节点 A、B，然后新建一个节点 C，把频率设置为两个节点的频率之和，并把 这个新节点 C 作为节点 A、B 的父节点。最后再把 C 节点放入到优先级队列中。重复这个 过程，直到队列中没有数据。

 

现在，我们给每一条边加上画一个权值，指向左子节点的边我们统统标记为 0，指向右子节 点的边，我们统统标记为 1，那从根节点到叶节点的路径就是叶节点对应字符的霍夫曼编 码