引言
本文为社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！
从开端开设《全解MySQL专栏》到现在，合计撰写了二十个大章节具体讲到了MySQL各方面的进阶技能点，从开端的数据库架构开端，到SQL履行流程、库表规划范式、索引机制与原理、事务与锁机制剖析、日志与内存详解、常用命令与高级特性、线上调优与故障排查…..，好像触及到了MySQL的方方面面。但到此为止就黔驴之技了吗？答案并非如此，以《MySQL特性篇》为分割线，整个MySQL专栏从此会进入“高可用”阶段的剖析，即从上篇之后会开启MySQL的新内容，首要叙述分布式、高可用、高功用方面的讲解。
接下来的数据库专栏内容，首要会讲解不同高并发场景下的
MySQL架构规划计划，也包括关于各类大流量/大数据该怎样优雅的处理，也包括架构调整后带来的后患又该怎样处理？其间内容会包括库内分表、主从复制、读写别离、双主热备、笔直分库、水平集群、分库分表实践、分布式事务、分布式ID、数据共同性评论……等内容。
话归正题，分库分表这个概念基本上碰过数据库的小伙伴都有听说过，但许多小伙伴对这块具体该怎样落地并不清楚，因而接下来这篇会先论述MySQL分库分表的方法论，以及具体讲解分库分表后发生的后患问题，但在此之前先送上一句话，请牢记：
不要为了分库分表而分库分表！！引入SOA架构中的一句话：架构不是一蹶而起的，而是渐渐演进的。只要真实需求分库分表来处理问题时，才去真实的做拆分，否则会导致许多不必要的费事发生，这点在《阿里Java开发规范手册》中有清晰的写出：
一、为什么需求分库分表？
在讲为什么需求分库分表之前，我们先来讲一个故事：在很久很久之前有一位名唤竹子的美男子，开端由于年幼并未娶妻生子，因而出行时都只需求一匹马来拉车，但随着年龄渐长，渐渐的开端娶妻纳妾，每次出行时的人数也会直线添加，而之前担任拉车的那匹老马却苦不堪言，由于随着日子一天一天的过，自身的压力也随之添加，终于有一天，老马扛不住了，累到在了大街上。
随即竹子也渐渐发现了这个问题，由于每次出行的人口越来越多，因而老马的才能无法满意出行需求，这时竹子为了处理出行问题，所以花费重金托人从西域购入了一匹身强体壮的汗血宝马，以此来寻求处理所遇到的困扰。
当商人将贵重的汗血宝马交给竹子时，这匹马确实比之前的老马才能强太多太多了，拖动一辆承载几人的马车彻底不在话下，一起竹子有了之前的前车之鉴，因而对其也分外看重，每天都吩咐人给宝马喂好料、做保养……，但好景不长，随着时刻推移，男人三妻四妾放在其时也并非罕事，所以这时这匹来自西域的汗血宝马也对此力不从心，渐渐的呈现乏力的状况。
此刻竹子也再次察觉到了这个状况，所以再次找到当初帮助购置汗血宝马的商人，想要再花重金买入一匹才能更强、体力更盛的千里马！但商人却道：“现在你手中的汗血宝马已属人间极品，想要找到比它更强且能替代它的少之又少，贵客您这需求恐怕老夫是难以完结咯”！
这时问题好像堕入僵局，但随之大行商便道：“尽管我无法替您寻找到更为优良的马匹，但我有一个万全之策能解你燃眉之急”！那这个彻底之策究竟是什么呢？此刻商人口中渐渐道出：“当一匹马无法处理你的出行问题时，与其寻找更好的马匹，为何不挑选用更多的马匹来拉车呢”？
此刻竹子一拍大腿，立马称赞道：所言极是，言之有理，所以大手一挥立马又购置了六匹良马，与之前的两匹旧马，组成了八匹马拉车的骑兵，自从之后，竹子再也没有遇到过出行问题。
在上面这个故事中，我们应该可以感受出来，当单匹马无法拉动马车时，不要企图找到一匹更好的马来替代，而是应该挑选运用多匹马来拉车！这个故事的内涵含义放在编程中同样如此，对一个节点做功用优化、晋级硬件装备便是再企图寻找一匹更健壮的马，但一匹马的力量再强也是有限的，所以这时挑选运用更多的马匹（服务器/节点）来处理问题才是王道！
编程里边有句话叫做：加一台服务器的收益胜过千万次调优，毕竟机器数量才是真理！
那么接着我们也回到问题自身，来一同聊一聊MySQL为什么需求分库分表？
1.1、恳求数太高
在高并发状况下，许多读写恳求落入数据库处理，终究会导致数据库的活泼衔接数添加，然后迫临乃至到达数据库可承载活泼衔接数的阈值。在事务Service层来看便是，可用数据库衔接锐减乃至无衔接可用，接下来面临的便是并发量急剧添加、吞吐量严峻下降、衔接呈现异常、数据库常常宕机、体系常常崩溃一系列后患问题。
1.2、数据查询慢
- 一、单表或单库数据量过大，导致数据检索的功率直线下降。
- 二、单库全体并发衔接数挨近体系阈值，然后导致此恳求获取不到衔接数，一向处于等待获取衔接的状态。
- 三、现已获取但由于并发过高导致
CPU被打满，就算SQL所查询的表数据行很少，也同样由于没有CPU资源无法履行，所以一向处于堵塞状态，终究呈现查询过慢的现象。
1.3、数据量太大
- ①当一个库的数据存储量太大时，就算每张表的并发数不多，可是由于是海量数据，单库中存在许多的数据表，每张表都有一部分并发恳求，导致终究单库的衔接数阈值成为数据库的瓶颈。
- ②当一张表数据太多时，导致单表查询速度严峻下降，尽管
InnoDB存储引擎的表答应的最大行数为10亿，可是假如一张表的数据行记录到达上亿等级，那就算通过索引去查询一条数据，它也需求至少通过上十次到几十次磁盘IO，然后导致单表查询速度直线下降；一般一张表的数据行数在800~1200W左右最合适。
1.4、单体架构的通病
单库中某张表遇到问题需求修复时，会影响了整个库中一切数据，由于有些严峻的状况下需求停机优化后从头上线，这时其它一些没有呈现问题的表，也会因而受到影响。
这就好比团队中一个人没完结好作业，所以导致整个团队一同陪同加班，这无疑很令人糟心。
1.5、MySQL数据库瓶颈
上面聊到的各类问题，本质上都是一些数据库瓶颈，一般程序的功用瓶颈都源自于硬件问题，而问题归根究竟都归于IO、CPU瓶颈，接下来聊一聊IO、CPU瓶颈可以细分红哪些呢？
2.1、IO瓶颈
IO瓶颈首要分为两方面，一方面是磁盘IO瓶颈，另一方面则是网络IO瓶颈，具体如下：
磁盘IO瓶颈
①在之前《MySQL内存篇》中曾具体讲到过，MySQL为了提高读写功用，通常都会将一些常常运用的热门数据放入缓冲区，防止每次读写恳求都走磁盘IO的方法去操作数据，但当整库数据数据太多时，或许会呈现许多的热门数据，此刻内存缓冲区中又无法悉数放下，因而会导致许多的读写恳求发生磁盘IO，通过读写磁盘的方法去完结数据读写，然后导致查询速度下降。
②一次查询数据的过程中，由于触及到的数据过多，导致无法悉数在内存中完结数据检索，如分组、排序、关联查询等场景，内存中相应的缓冲区无法载入要操作的悉数数据，因而只能通过分批的方法处理数据，此刻又需求通过许多磁盘IO后才得到终究数据集。
这种状况在单表查询时也存在，假如单表中字段过多，导致每一行数据的体积都比较大，因而会超出
MySQL磁盘IO每次读取16KB的这个限制，因而也会呈现检索单表数据时，一条数据就需求通过屡次IO才干拿完。
简略来说磁盘IO瓶颈有两种状况，一种是磁盘IO次数过多，导致IO利用率继续居高不下，另一种状况便是每次读取数据都超出单次IO的最大限制，因而会引发屡次IO，然后又演变成第一种状况。
网络IO瓶颈
当一个恳求的生成的SQL句子履行后，由于这条句子得到的成果集数据太多，然后会导致相应时的数据包体积过大，这时假如网络带宽不够，就会呈现传输过慢的问题，由于底层需求对大的数据包做拆包，然后分批回来，这时也会堵塞其它读写数据的恳求，网络带宽就会成为新的瓶颈。
其实网络
IO瓶颈的状况也比较好了解，网络带宽就好比一条马路，由于一条SQL回来的成果集过大，因而装载数据包的货车远远超出了马路的宽度，这时就需求将数据拆分到多辆能通行的小货车装载，但尽管这样做可以让数据包“变窄”成功回来，但因而也会形成这个大数据包会变长，然后占满整个带宽通道，因而其它网络数据包需求等这个大包传输完结后，才干继续通行。
2.2、CPU瓶颈
上面简略的了解IO瓶颈后，再来看看机器自身的CPU瓶颈，CPU瓶颈也会分为两种，一种是运算密集型瓶颈，另一种则是堵塞密集型瓶颈，但想要弄清楚这两种瓶颈，我们首先得了解CPU的作业原理。
CPU作业原理
有深入研究过多线程编程的小伙伴，关于CPU的作业原理应该并不陌生，线程是操作体系最小的履行单元，因而CPU作业时本质上便是以线程作为载体，然后履行线程任务中的一条条指令，一般状况下单核CPU在同一时刻只可以支撑单挑线程运转，但随着2002年超线程技能的发布后，如今的CPU通常具有两组ALU履行单元，也便是我们常听到的单核双线程、四核八线程…..
由于超线程技能的存在，所以一核
CPU在同一时刻可支撑两条线程一同运转，这种结构的CPU在现在也被称为大核架构，即一中心具有两逻辑处理器。而传统的单核单线程的CPU则被称为小核架构，现在最新的12/13代CPU还有巨细核异构的架构。
但无论是小核、大核、巨细核架构的CPU，本质上在机器运转期间，往往整个体系内一切程序的线程数，加起来之后都会远超于CPU核数，如下：
那在这种状况下是怎样作业的呢？信任有相关知识储藏的小伙伴第一时刻就会想到一个词汇：时刻片切换履行，也便是有限的CPU中心会在一切线程之前来回切换，以此来确保体系和程序的正常运转。
其间的原理简略了解起来也并不难，由于每条线程的指令在履行时都需求数据作为基础，因而
CPU在履行某条指令后，履行新指令时需求加载数据，此刻会去载入数据，而操作体系这时就会将CPU资源切换给其它的线程履行，等这条线程的数据预备好了再切换回来。
浅显层面的原理如上，再深入一些会触及总线、I/O设备原理、活泼进程算法、资源切换原理……等一系列技能了，这儿先就此打住，我们只需求了解到这儿就够用啦！接着再回去聊聊所说的两种CPU瓶颈。
运算密集型瓶颈
用户恳求生成的SQL句子中包含许多join联表查询、group by分组查询、order by排序等之类的聚合操作，一起这些操作要依据特别大的数据集做运算，导致履行时耗费许多CPU资源，CPU占用率直达100%+，因而无法再给其它线程供给履行所需的CPU资源。
堵塞密集型瓶颈
一张或多张表的数据量特别大，此刻依据这些大表做数据检索时，需求扫描的数据行太多，尽管这些SQL句子不会许多耗费CPU资源，但由于数据量过大，会导致长期占用CPU资源，然后形成其它线程无法获取CPU资源履行。
上面聊到的两种
CPU瓶颈中，一种归于许多运算导致CPU资源耗尽，一种归于大表检索导致长期占用CPU资源，两种状况都会导致CPU遇到瓶颈，然后无法给其它线程供给运转所需的资源。有人也许会说，好像这是SQL不合理导致的呀？其实不然，由于往往许多正常的SQL也会呈现许多耗费CPU、或检索大表数据长期占用CPU的状况。
无论是IO瓶颈，仍是CPU瓶颈，都可以通过晋级硬件装备的方法来处理，比方晋级磁盘原料、加大网络带宽、增多CPU核数等，但前面讲到过，这种方法面临高并发大流量的冲击，治标不治本！假如客户端流量过大，这时不应该再企图寻找更健壮的马来替代，而是应该挑选多匹马的计划来处理。
其实这也是一种节约本钱的做法，无限制晋级硬件也不是持久之道，而且越到后期，装备越高的硬件本钱越高，四颗八核十六线程的
CPU，本钱价或许还会比一颗32Core 64Thread的CPU要便宜。
1.6、再聊为何需求分库分表
其实不论是并发过高、或拜访变慢、亦或数据量过大，本质上都归于数据库遭遇到了瓶颈，但只不过依据状况不同，分为不同类型的数据库瓶颈，可是终究关于客户端而言，便是数据库不可用了或许变慢了。
而导致数据库呈现此类问题的原因，实则便是随着事务的开展，体系的数据不断增多、用户量不断添加、并发量不断变大，因而关于数据再进行
CRUD操作的开支也会越来越大，再加上物理服务器的CPU、磁盘、内存、IO等资源有限，终究也会限制数据库所能承载的最大数据量、数据处理才能。
当呈现上述这类问题，而且无法通过晋级硬件、版本、调优等手法处理时，或许只能暂时处理，却无法保证未来事务添加的可用性时，此刻就需求合理的规划数据库架构来满意不断添加的事务，这便是分库分表诞生的初衷，意图便是为了防止单库由于压力过高，导致呈现之前所说的一系列问题，合理的规划架构能最大限度上进步数据库的全体吞吐量。
下面为了可以更好的讲透彻分库分表的方法论，我将以一个真实事例给我们论述分库分表的架构演进过程。
二、传统单库架构到分库分表的演进史
早些年我司新开一条事务线切入金融领域，最开端的由于忧虑危险过大，所以并未投入太多的本钱，处于一个试错阶段，开端就把一切事务都怼入一个war包，一切事务同享一个库资源，结构大致如下：
而在其时那段时刻，金融领域快速开展，渐渐的，Java建立的金融中心体系开端呈现响应变慢，乃至时不时宕机，布置整个金融中心体系的单台Tomcat很快遇到了瓶颈，后来实在由于Tomcat三天俩头宕机重启，迫于无奈开端了事务架构的改进，如下：
由于其时考虑到事务开展速度，并没有运用Nginx对Tomcat进行横向拓宽做水平集群，由于假如仅仅只是通过Nginx来做，或许今后仍是需求对架构进行晋级，进一步按事务拆分红分布式体系，所以经评论后共同决议直接引入分布式架构对体系进行改造。
通过改造后的事务架构，
Java运用这边确实可以抗住每天的流量，但其时由于在做Java程序架构晋级的时分，只引入了Redis、MQ下降数据库并发，并没有去对数据库做太多的拓宽，因而其时仍是一切事务同享一个库。
随着时刻的渐渐推移，尽管用MQ、Redis做了流量的削峰，可是也挡不住其时的流量恳求，做过金融事务的小伙伴应该清楚，它不像其他事务领域中读多写少，金融事务中读多写也多，一起还需求每日对账、跑批、统计报表…..，因而对数据库的读写操作适当多，而金融事务又要求数据实时性，所以许多操作无法走MQ异步完结，也不能放入Redis做数据缓存，Why？
好比拿股市中最基本的买入卖出为例，本来客户看到的是
5$一股，然后用户挑选了买入，由于数据放在缓存里没有及时更新，成果最新价格成了10$一股，此刻用户买入10000$，按用户的预估应该是会买入2000股左右，成果终究买成了1000股，平白无故导致用户追涨。
也包括许多的写操作也无法走MQ异步完结，比方用户以5$的本钱价买入，现在看到了最新的价格为10$一股，然后挑选了全仓卖出，这时你将卖出操作发给了MQ异步履行，成果MQ中的卖出消息并未立马被消费，而是到了一小时后价格降到了2.5$一股时，才真实被消费，这回导致本来用户能赚100点，最终反变为倒亏50点。
尽管其时手上的项目并非交易所类型的金融事务，但无论是哪类金融事务，基本上对数据的实时性要求特别高，所以MQ、Redis基本上只能分担很小一部分的流量，其它大部分的流量仍旧会需求落库处理。也正因如此，终究数据库成了整个体系的瓶颈口，为了去处理这个问题，终究选用服务独享库的计划进行晋级（也便是后续要说的笔直分库模式），如下：
而数据库这边通过拆分之后，相较于之前的单库架构，整个数据库体系的稳定性和可用性显着得到改善，但由于某些库是常常需求被拜访到的（资金库、信审库、后台库），所以这些中心库以单节点方法去承载流量仍是显得有点吃力（吞吐量下降、响应速度变慢），终究又对中心事务库进行横向扩容，架构如下：
终究，依据服务不同的事务规划，拆成了规划不同、事务不同的库，可是这其间的拆分规矩究竟是什么呢？以及拆分的依据又是啥？接着一同来聊一聊！
三、分库分表正确的拆分手法
现在你的手里有一个西瓜，吃的时分切法有两种，一种是以笔直方向竖切，另一种是以水平方向横切，如下：
这种切割方法在分库分表中也存在，分库分表的拆分规矩也可分为：水平、笔直 两个维度。
但水平、笔直该怎样拆？什么场景下拆？拆完会呈现的问题又该怎样去处理呢？那么接着来一步步剖析究竟怎样拆，拆完的问题怎样去处理~
留意：分库、分表是两个概念，两者并不是同一个名词，所以这儿需求牢记！按拆分的粒度来排序，合计可分为四种计划：笔直分表、水平分表、笔直分库、水平分库。
3.1、不同场景下的分表计划
分表大多是在单表字段过多或数据过多的场景下，会挑选的一种优化计划，当一个表字段过多时，应当考虑笔直分表计划，将剩余的字段拆分到不同的表中存储。当一个表的数据过多时，或许数据添加速率过快时，应当考虑通过水平分表计划，来下降单表的数据行数。
3.1.1、笔直分表：结构不同，数据不同（表等级）
当一张表由于字段过多时，会导致表中每行数据的体积变大，而之前不仅一次聊到过：单行数据过大带来的后患，一方面会导致磁盘IO次数增多，影响数据的读写功率；一起另一方面成果集响应时还会占用许多网络带宽，影响数据的传输功率；再从内存维度来看，单行数据越大，缓冲区中能放下的热门数据页会越少，当读写操作无法在内存中定位到相应的数据页，然后又会发生许多的磁盘IO。
从上述的几点原因可显着感受到，当单表的字段数量过多时，会导致数据检索功率变低、网络响应速度变慢、数据库吞吐量下降等问题，面临于这种场景时，就可以考虑笔直分表。
例：现在有一张表，总共43个字段，可是关于程序来说，一般常常运用的字段不过其间的十余个，而这些常常运用的字段则被称之为热门字段，假设此刻这张表中的热门字段为18个，剩下的冷字段为25个，那么我们就可以依据冷热字段来对表进行拆分，如下：
对字段过多的表做了笔直拆分后，这时就能很好的控制表中单行数据的体积，然后可以让常常运用的字段数据更快的被拜访、更快的回来。不过在做笔直拆分时，记住在冷字段的表中多加一个列，作为热字段表的外键映射，确保在需求用到冷数据时也能找到。
关于这种笔直分表的场景在许多事务中都有完成，如用户数据会分为
users、user_infos，订单数据会分为order、order_info......。所谓的笔直分表其实和之前《库表规划篇》中聊到的范式规划，大致含义是相似的，假如表结构是依照数据库三范式规划的，基本上也无需考虑做笔直分表。
通过笔直拆分后的两张或多张表，各自之间的表结构不同，而且各自存储的数据也不同，这是笔直分表后的特性，以上述比方来说，热门字段表会存储热数据，冷字段表会存储冷数据，两张表的拼接起来后会组成完好的数据。
3.1.2、水平分表：结构相同，数据不同（表等级）
前面聊到了字段过多对读写数据时的影响，接着再来看看数据过多时会导致的负面影响，尽管数据库中有索引机制，可以确保单表在海量数据的基础上，检索数据的功率仍旧可观，但随着数据不断添加，当到达千万等级时，就会呈现显着的查询功率下降的问题。
这儿所谓的查询功率下降并非指单表的简略查询句子，而是指一些杂乱的
SQL句子，毕竟线上往往许多需求，都要通过杂乱的SQL运算后才干得到数据，比方多张表联查再跟了一堆分组、排序、过滤、函数处理…..句子，这种状况下再依据这种大表查询，就算走了索引，功率也不会太高，由于其间要触及到许多数据的处理，因而面临这种状况，就可以对表进行水平拆分。
例：现在有一张表，里边有三千万条数据记录，当依据该表去履行一条在索引上的杂乱SQL时，也需求必定时刻，至少会比1000万的数据表慢了好几倍，此刻可以把这张3000W的表，拆为三张1000W的表，如下：
对一张大表做了水平分表之后，我们可以很好的控制单表的数据行数，3000W条数据的表和1000W条数据的表，查询速度其实不仅仅只是3倍的差距，数据过了千万等级时，数据量每向上添加一个量级，查询的开支也会呈直线性添加，因而做水平分表时，一般要求控制在500-1200W之间为一张表。
阿里内部的单表数据量大约控制在
500~600W一张，由于这个数据量级，就算运用分布式战略生成的分布式ID作为主键，也可以很好的把索引树高控制在3~5以内，也就意味着最多三到五次磁盘IO就必定能得到数据，然后将单表的查询功用控制在最佳范围内。
水平拆分之后的两张或多张表，每张表的表、索引等结构彻底相同，各表之间不同的当地在于数据，每张表中会存储不同范围的数据。不过拆分之后的水平表究竟会存储哪个范围的数据，这要依据水平分表的战略来决议，你可以按ID来以数据行分表，也可以按日期来以周、月、季、年…….分表。
PS：诸位看下来应该会发现，水平分表的计划和之前聊到过的《MySQL表分区技能》十分相似，但这不意味着表分区可以替代水平分表，答案恰恰相反，一般要用表分区的场景中可以挑选水平分表的计划来替代。
3.1.3、分表计划总结
分表计划首要是针关于单表字段过多或数据过多的状况去做的，通过笔直、水平分表的手法，可以很优点理单表由于字段、数据量过多发生的一系列负面影响，但无论是笔直分表仍是水平分表，都有必要建立在单库压力不高，可是单表功用不够的状况下进行的，由于它们都归于库内分表。
假如是数据库全体压力都很大的状况，然后导致的查询功率低下，那不论再怎样做分表也杯水车薪，毕竟连流量入口都呈现了拥塞，自然分表也无法处理问题，所以分表操作只建立在单库压力不高，可是单表查询功率低下的状况适用。
好比把数据库比作一个游乐园，而表则可以比作里边的一个个文娱项目，由于某些文娱项目比较火爆，因而可以对同一类型的项目多开几个，然后处理热门项目顾客要排队很久才干玩的问题。但假如是整个游乐园的人流量都非常大，每个项目都有许多顾客排队，这时再去对内部的文娱项目作拓宽，这种方法是行不通的，毕竟游乐园的大门就那么大，游客连进大门都要排队，再在内部作项目拓宽显然杯水车薪。
3.2、不同场景下的分库计划
通过前面的分表总结后可以得知：假如是由于库等级的压力较大，这时就需求考虑分库计划，而不仅仅是分表计划，换到上面的比方中，当整个游乐园的人流量非常大时，应该考虑的是开分园，而并非是在内部作拓宽。
分库和分表相同，也可以按笔直和水平两个维度来分，笔直分库本质上便是按事务分库，也便是现在分布式/微服务架构中，事务独享库的概念，而水平分库则是对同一个节点作横向拓宽，也便是高可用集群的概念。
3.2.1、笔直分库：结构不同，数据不同（库等级）
当数据库运用单机的结构布置，在大流量/高并发状况下遇到瓶颈时，此刻就可以考虑分库计划了，首先来聊聊笔直分库。
在项目开发过程中，一般为了便利团队分工合作和后续办理保护，通常都会对单个项目划分模块，依照事务特点的不同，会将一个大的项目拆分为不同的模块，一起每个事务模块也会在数据库中创建对应的表。
而所谓的笔直分库，便是依据事务特点的不同，将单库中具有同一事务特点的表，悉数独自拧出来，放在一个独自的库中存储，也就按事务特性将大库拆分为多个事务功用单一的小库，每个小库只为对应的事务供给服务，这样可以让数据存储层的吞吐量呈几何倍添加。
例：以前面给出的金融项目来说，当单个库无法承载整个事务体系发生的流量压力时，比方此刻单个数据库节点的QPS上限为2000，但事务高峰期抵达数据库的瞬时流量，形成了2W个并发恳求，这时假如处理不当，数据库基本上会被这波瞬时流量打宕机。
关于前面所说的这种状况，就可以考虑依据事务特点拆分整个大库了，中心思想便是：既然单个节点扛不住，那就加机器用多个节点来抗，在客户端依照不同的事务特点，将过来的恳求依照不同的事务特性做分流处理，如下：
本来之前单库时，无论是查询用户事务相关的SQL句子，仍是放款/还款之类的SQL句子，不论三七二十一通通发往同一个数据库处理，悉数都由这一个数据库节点供给数据支持，但按事务特性做了笔直分库后，用户相关的读写恳求落入用户库，放款/还款之类的读写恳求会落入资金库…..，这样就能很好的去应对单库面临的负载过高问题。
笔直分库后，每个库中存储的数据都不相同，由于是依照事务特性去将对应的表抽出去了组成新库，所以库结构也是不同的，用户库是由用户相关的表组成、信审库是由心生相关的表组成…….。
3.2.2、水平分库：结构相同，数据不同（库等级）
通过前面的笔直分库后，依据不同的事务类型，将拜访压力分发到不同的库处理后，尽管在极大程度上提高了数据层的负荷才能，但假如某类事务的并发数仍旧很高，比方通过前面的事务分流后，假设平台库需求承载5000的并发、信审库仍旧需求承载1W的并发，这也远超出了单个数据库节点的处理瓶颈，终究或许仍是会能把对应的数据库节点打宕机，所以此刻可通过水平分库的计划，来提高某类事务库的抗并发吞吐量。如下：
通过水平拆分的计划，可以依据压力的不同，分配不同的机器数量，然后使得不同库的抗压性都能满意对应的事务需求，这也就相似于分布式/微服务项目中，对单个服务做集群确保高可用的战略。
水平分库是依据一个节点，然后直接横向拓宽，这也就意味着同一事务的数据库，各节点之间的库结构彻底相同，但每个节点中的数据是否相同，这就要看你自己去决议了，一般状况下都是不同的，也便是不同节点的库会存储不同范围的数据。
3.2.3、特殊的分库计划
前面聊清楚了分库分表中经典的笔直分库和水平分库计划，但除开这两种之外，还有一些特殊的分库计划，也便是指一些数据库的高可用计划，例如主从复制、读写别离、双主热备等计划。
主从计划：一般会建立读写别离，写恳求发往主节点处理，读恳求发往从节点处理，从节点会彻底同步主节点的数据，然后完成读写恳求分开处理的效果，可以再必定程度上提高数据存储层全体的并发处理才能。一起当主机挂掉时，从机也可以在很快的时刻内替换成主机，以此确保数据层的高可用。
多主计划：一般是双主计划，两台数据库节点之间互为主从，彼此同步各自的数据，两台节点中都具有完好的数据，读写恳求可以发给任意节点处理。相较于前面的主从读写别离架构，这种双主双写架构的灾备才能更强，由于当其间某个节点宕机时，另一个节点可以彻底接替对方的流量，不存在从机切换成主机的时刻开支，因而可以确保数据100%不丢失。
不过无论是主从、仍是多主计划，本质上都存在木桶效应问题，由于这种分库计划中都会彻底同步数据，当一个节点的数据存满时，会导致其他节点也不可用，关于这儿的具体原因可参阅《MySQL优化篇-架构优化》。
四、分库分表总结
分库计划可以在最大程度上提高数据存储层的功用，但一般在考虑选用分库计划时，应该先考虑运用主从、主主的计划，假如前面两种计划仍旧无法供给体系所需的吞吐量，再考虑挑选笔直分库计划，依照事务特点去划分库结构，最终才应该考虑挑选水平分库计划（一起也要记住考虑数据的添加速率状况）。
那为什么需求遵从这个顺序呢？由于架构不能过度规划，选用主从、主主可以满意需求时，就选这两种计划，由于一方面能防止许多问题发生，一起完成起来也比较简略。一起先考虑笔直分库，再考虑水平分库，是由于水平分库可以建立在笔直分库的基础上，进一步对存储层作拓宽，因而灵活性会更高，拓宽性会更强。
一起最终再聊一下分库之后带来的优点：
- ①可以得到最大的功用收益，吞吐量会随机器数量呈直线性添加。
- ②可以最大程度上保证存储层的高可用，任意节点宕机都不会影响全体事务的运转。
- ③具有适当强的容错率，当一个库中的结构存在问题需求重构时，无需将一切事务停机更新。
- ④具有高稳定性，分库+配备完善的监控重启战略后，基本上能确保线上无需人工介入办理。
也便是说，分库计划可以让你的存储层真实到达高可用、高功用、高稳定的“三高”水准。
但要牢记不能盲意图分库分表，分库分表前得先清楚功用瓶颈在哪里，然后依据事务以及瓶颈，遵从拆分规矩的顺序做合理的拆分计划挑选，由于分库分表尽管能带来很大的优点，可是一起也发生了一系列的问题需求去处理。
假如做了分库分表就必定要记住：既不能过度规划，也要考虑数据添加性，提早规划好扩容计划，以便于后续功用再次呈现瓶颈时，可以依据现有架构进行优雅晋级，一位优秀的开发/架构有必要具有前瞻性。
但关于怎样规划出一套合理的扩容计划，也包括分库分表后究竟会发生哪些后患问题，这些问题发生后又该怎样处理，具体的内容可参阅下篇：《分库分表后患问题一站式处理计划》。
