18.分库分表原理

好，第三章咱们了解过分库分表相关概念，那这第五章咱们就要动手去做这个分库分表啊，咱们要去什么呢？诶，通过实践还有这个理论的了解，去掌握分库分表，那还是那句话，我为什么要用它啊，这个分库分表咱们在第三章了解它是什么，那第五章咱们就先了解一下他为什么要使用分库分表，再一个就是怎么去用啊，带着各位咱们把这个分库分表掌握，那这块呢，其实为什么要用它很简单，就是为了解决实际的应用问题啊，咱们现在应用问题就是什么？诶如果是很简单的那个，比如内部使用的系统程序或者什么呢？诶咱们没有放在互联网上，哎，使用的这些小的程序啊，啊，用户量数据量没那么大啊，用不着做这个风控分表啊，但是呢，只要是放在互联网上，咱们就有可能会面对高访量高并发，呃，用户量会什么呢？会呃，这个增长很多，访问量也会增长很多，数据量同量会增长很多。

啊，这是什么呢？诶，如果一个劲儿的往买思Q数据库里面C的话，买思Q数据库是有瓶颈的啊，单库有单库的瓶颈，单表有单表的瓶颈啊，但凡达到瓶颈了，那查询数据就会非常慢，甚至于说查不出来，那怎么办啊，这个按照咱们呃基本理念，按照咱们的这个搭建应用的基本理念，按照咱们的存储数据的基本理念，咱们是不是一台机器扛不住，一个数据库扛不住，哎，我多来几个数据库啊。哎，这个兄弟多一块儿扛，这样是不是就能扛住了啊，所以这块呢，分股分表的基本理念就是做一个数据库的一个什么呢？呃，一个分布式啊，这块呢，我多台机器啊，这个搭成咱们整个这个分布式的架构，一块儿去扛，这个高仿量，高并发，高数据量啊，实现咱们的应用的正常使用，高效使用啊，这就是它的基本理念啊，说白了就是一个数据库啊，有很多表构成，每个表呢又有不同的业务啊，咱们什么呢？可以进行一个垂直切分，也就是咱们所说的分库啊，分布到不同的数据库，放在不同主机上，也可以进行什么呢？诶水平拆分分表啊，把这个数据再进行个分片，就同样是分在不同数据库上来，放在不同主机上啊，这就是咱们的分库分表的基本理念，垂直拆分分库啊，就根据咱们业务场景，把一个单个的什么的，整体的啊，一个业务数据库拆分成，比如说用户系统啊，订单系统啊，支付系统啊，哎，这个分成。

一个一个系统的专门的数据库啊，当然也同样分在不同主机上啊，如果在一台主机上创建多个库没什么意义啊，咱们都是分到不同主机上，呃，这个完成了咱们的对应的切分，那同样也可以把它什么的进行什么的单个，呃，咱们的数据库里面啊，单个一张表也可以进行拆分，咱们先说说这个分库啊，带着各位先了解分库，然后呢，咱们再说说分表啊，这首先分库啊，第一个问题啊，就是咱们的呃，两台主机上的两个数据库中的表能否进行关联查询，各位一定要注意啊，是不可以的啊，这块如果在一台机器上诶，不同的数据库里面，我倒诶可以进行个关联查询，但是如果是分在两台主机上。

呃，两个不同数据库的表是没办法进行关联查询的，那这块呢，咱们分库的基本原则其实很简单，就是什么呢？有紧密关联的表应该分在一个库里面啊这块呢，呃，相互之间没有关系的表，我可以进行拆分，分在不同库，因为我说所说的这个库是在不同主机上啊，就跟上面这块一样，诶咱们的用户跟订单相关联啊，这块呢，哎，但是他这块没有那种强的什么关联的需求，所以这块呢，用户所有的信息全放在用户库里面，而咱们的订单所有的信息全放在订单库里面啊这是什么呢？把它进行拆分，就跟底下这个实例啊，咱们带各位简单看一下这个例子，比如说哎，我这儿有这么一个电商平台啊，里面有相关的数据库啊，咱们有customer啊，客户表已经有20万数据了，还有咱们的订单表啊，600万数据啊，这个数据量已经很很大了，诶，上百万对于咱们的MYS来说已经快到瓶颈了。

啊，查询会明显变慢啊，所以咱们需要考虑优化的事儿，好了再往后啊，咱们的订单详情表啊，这个跟咱们订单表这个紧密关联啊，这块有600万，然后呢，这个订单状态字典表有20条，那这块应该怎么划分，其实这个很好去划分啊，咱们说过划分原则就是诶，这个不会出现紧密关联，也就是不会出现桌印的表啊，不会出现咱们的关联查询的表进行划分，我应该怎么划分啊。咱们是不是直接把这个什么呢？诶把咱们的客户表给它拆出来就可以了，呃，完成咱们的什么呢？诶这个数据表的一个分库操作啊，把不会进行桌引关联的信息客户表提出来，你说老师这不是有关联吗？这有这这有外建是有外建，各位回忆一下，咱们访问啊电商平台是怎么操作，你是不是得先登录啊，啊登录之后自然而然系统中啊内存中有用户信息啊，咱们能拿到用户信息，那你但凡访问这个用户相关订单的时候，我不需要整个表进行关联啊，我只需要拿到你用户ID就可以了，根据ID作为外键，是不是查询就成了，它就是一个筛选条件。

啊，所以说相对而言这个，诶咱们的customer客户表跟这个订单表，哎，这个我们不存在紧密的关联关系，所以咱们把这个customer表诶提出流程，当然围绕着咱们的客户表，肯定还有一堆跟客户相关联的信息啊，比如咱们客户详情啊，哎客户的一些什么呢？呃，一些认证啊，诶客户的一些别的一些信息啊，像这个客户相关的信息，我是不是同样放在用户表就可以了。诶，把这个相关联的表放在同一个数据库啊，这就是咱们的分库的基本理念，咱们把它了解清楚就成啊这块呢，以这个，呃，咱们举着这个小DEMO为例啊，咱们简单的了解就可以，好，那下面那就说怎么分表了啊，这分完库了，咱们得说说分表了，因为摆在咱面前呢，一个600万，另外一个也是600万，你是不是应该进行拆分啊，那这块呢，怎么进行分表啊，咱们也需要了解，有同学想到说老师，那我干脆就根据ID，根据他创建这个记录的时间分行不行啊，这样分可以啊，但是呢啊，有些场景就不太合适了啊，比如说咱们电商平台，如果你用这个ID或者时间分，那我想问一个问题了，就是什么呢？你分表如果按照ID或者时间分，那我想问问哪个什么的数据库里面，哎，哪个数据分片里面存618或者双11那天的订单。

那哪个数据库里面存对，哪个数据库是不是也存不下，对吧？诶如果是一个电商平台，尤其是像那个电商巨头啊，它的订单量那么大，尤其是在什么呢？618双11这种购物节的这种前提下啊，有各种各样的活动，各种各样的什么呢？哎，这个秒杀啊，这类似的一些促销活动，那这块呢，哎，就会出现高访量，高并发啊，高什么的下单的数量，那各位这些东西你塞到哪个数据分配啊，都塞不下啊，你会把表承报的。

啊，那怎么办？哎，咱们不能按照这个ID或者时间去分，咱们看一下如何分表呢？哎，咱们买思扣哎单表啊这个什么存储数据的这个量是有什么瓶颈的，哎单表达到1000万数据就达达到达了它的瓶颈了啊会影响咱们查询效率的，咱们要进行一个优化，哎比如说例子通啊，咱们刚刚说了啊，哎都是600万，我应该怎么进行优化啊，这块得说一下怎么进行优化呢？哎，这个首先第一个我可以拿主见或者创建时间分，但这样分不平均就会造成啊有些表啊，有些数据分片里面，它的数据量会很少。啊，就是这一些什么呢，有些时间啊，这个就是全民啊，都不不热衷于购物啊这块或者普通日子，哎，本身下单量就是就少，那这块呢，但凡碰到这个访问高峰啊，咱们的双十一六幺八，那这个量又太大，那怎么办？用它分很明显不合适，那应该换成谁？各位是不是换成customer哎根据customer ID区分用户ID客户ID去分是不是更合适啊。

啊这样的什么呢？好处什么？首先分的比较平均啊，这块呢啊，同样同一个客户他所有的订单全都在一个数据分片啊，查询效率也会非常高啊，不会说是诶我这儿分成十个数据分片啊，我这个什么呢，一个用户去查，然后呢，这块呢，十个数据库都给这一个客户啊提供服务啊这样什么呢，也是有点浪费资源，浪费咱们的性能啊，一般情况下诶，咱们同一个客户就放在同一个数据分片就成啊一个用户他订单量都不会太大啊，就算你是专业买买专业买手啊啊你的这个什么专业采购人员，你的这个订单量也不会太大，不会超出咱们的，诶这个数据分片啊，这个相应的限制啊，咱们不会超出这个买S的平颈，所以这块呢，诶，咱们按照客户ID区分更合适一些啊，分的数据更平均啊，这就是哎咱们的所说的这个分表的这个相关原则，还是那句话，咱们以这个实啊实际的这个DEMO例子为例啊，咱们去什么呢？呃了。

解一下怎么进行分库，怎么进行分表，但是哎还是那句话啊，咱们各位同学需要注意，分库分表是一个整体操作啊，整体需要进行规划的啊，咱们并不是割裂的，来去什么呢？呃，去了解它去什么呢？搭建它啊有同学说老师那这个你一点多的那个版本的时候，确实是分不开来去搭建呢，确实是因为咱们什么呢，为了了解这个概念，为了了解怎么去做啊，但是按照这个买cat的，诶，这个什么官方文档的规定啊，分库分表都是同时在做啊，先进进行分库的这个配置，再进行分表的配置，这样什呢，咱们最终达成更高效的数据库分布式啊，分库分表一块儿去实现咱们的，呃，这个数据库分布式啊，这块呢，在买cat特尔深有体会啊，深有什么呢？诶一个什么支持啊，深有的一个这个概念的一个，诶凸显啊，咱们可以看到买KS2，哎，就是把分库分表完全融合到一块儿了，而且。

再次简化啊，咱们最开始啊这个去搭建这个什么呢？之前搭建这个读写分离的时候，各位就有所体会啊，咱们不需要改过过多的去改配置文件了，咱们可以用什么是不是那个注释脚本语啊，就注释脚本语言去实现这个相关的，呃，咱们的呃这个读写分离的搭建，搭建各个元素，然后去实现它，同样分库分表更能深刻体会出来，哎买CA2给咱们进行一个便利啊，咱们可以什么呢？把myca提呃启动起来，直接在买客户端，诶运行脚本就可以实现咱们的什么的分库分表啊，你说老师运行什么脚本很简单，建表脚本，建库脚本就可以啊，你说老师那怎么去做，不着急啊，咱们把这个理念了解清楚啊，咱们明确为什么要做分库，为什么要做分表之后，那下面就什么是不是该怎么去做了，我带着各位咱们去实现分库分表。