MySQL大概上可分为Server层和保存引擎层两部份。
Server层：承接器：TCP握手后效劳器来考证登岸用户身份，A用户创立承接后，经管员对A用户权力更正了也不会影响到曾经创立的链接权力，一定从头登岸。盘问缓存：盘问后的效果保存场所，MySQL8.0版本往后曾经撤消，由于盘问缓存生效太频频，因小失大。解析器：按照语法例则，决断你输入的这个SQL语句是不是满意MySQL语法。优化器：多种实行政策可完结标的，系统主动取舍最优实行实行。实行器：决断是不是有权力，将终究职责提交到保存引擎。保存引擎层负责数据的保存和讨取。其架构形式是插件式的，赞成InnoDB、MyISAM、Memory等多个保存引擎。目前最罕用的保存引擎是InnoDB，它从MySQL5.5.5版本着手成为了默许保存引擎(经罕用的也是这个)。
SQL实行递次2、BinLog、RedoLog、UndoLogBinLogBinLog是纪录所罕见据库表组织改变（比方create、altertable）以及表数据更正(insert、update、delete)的二进制日记，主从数据库同步用到的都是BinLog文献。BinLog日记文献有三种形式。
STATEMENT形式
实质：binlog只会纪录或者引发数据改变的sql语句
上风：该形式下，由于没有纪录理论的数据，于是日记量和IO都耗费很低，功用是最优的
劣势：但有些职掌并不是断定的，譬喻uuid()函数会随机形成独一标帜，当依赖binlog回放时，该职掌生成的数据与原数据一定是不同的，此时或者形成无奈预见的恶果。
ROW形式
实质：在该形式下，binlog会纪录屡屡职掌的源数据与更正后的标的数据，StreamSets就请求该形式。
上风：也许绝对精确的复原，进而保证了数据的平安与牢靠，而且复制和数据复原经过可于是并发实行的
劣势：毛病在于binlog体积会特别大，同时，关于更正纪录多、字段长度大的职掌来讲，纪录时功用耗费会很严峻。赏玩的时辰也需求特别指令来实行读取数据。
MIXED形式
实质：是对上述STATEMENT跟ROW两种形式的搀杂应用。
细节：关于绝大部份职掌，都应用STATEMENT来实行binlog的纪录，惟有下列职掌应用ROW来完结：表的保存引擎为NDB，应用了uuid()等虚浮定函数，应用了insertdelay语句，应用了暂时表
主从同步过程：
1、主节点一定起用二进制日记，纪录任何更正了数据库数据的事情。
2、从节点开启一个线程（I/OThread)把本身饰演成mysql的客户端，经过mysql协定，哀求主节点的二进制日记文献中的事情。
3、主节点启动一个线程（dumpThread），审查本身二进制日记中的事情，跟对方哀求的场所比较，要是不带哀求场所参数，则主节点就会从第一个日记文献中的第一个事情一个一个发送给从节点。
4、从节点领受到主节点发送过来的数据把它安插到中继日记（Relaylog）文献中。并纪录该次哀求到主节点的详细哪一个二进制日记文献内部的哪一个场所（主节点中的二进制文献会有多个）。
5、从节点启动此外一个线程（sqlThread），把Relaylog中的事情读掏出来，并在内陆再实行一次。
mysql默许的复制方法是异步的，而且复制的时辰是有并行复制本领的。主库把日记发送给从库后无论了，如许会形成一个题目便是假如主库挂了，从库解决失利了，这时辰从库升为主库后，日记就丧失了。由此形成两个观念。
全同步复制主库写入binlog后强逼同步日记到从库，总共的从库都实行告竣后才返回给客户端，然则很显然这个方法的话功用会遭到严峻影响。
半同步复制半同步复制的逻辑是如许，从库写入日记胜利后返回ACK确认给主库，主库收到起码一个从库确实认就以为写职掌告竣。
还也许延长到由于主从建设不同样、主库大事情、从库压力过大、网络震撼等形成主备推迟，怎样防止这个题目？主备切换的时辰用牢靠性优先准则仍是可用性优先准则？怎样决断主库Crash了？互为主备环境下怎样防止主备轮回复制？被删库跑路了怎样准确复原？(⊙o⊙)…觉得越来越扯到DBA的活儿上去了。
RedoLog也许先经过上面demo懂得：
饭点记账也许把账单写在账本上也也许写在粉板上。有人赊账或者还账的话，时时有两种做法：
1、直接把账本翻出来，把此次赊的账加之去或者扣除去。
2、先在粉板上记下此次的账，等打烊往后再把账本翻出来核算。
买卖忙时选后者，由于前者太费事了。得在数不胜数的纪录中找到这部分的赊账总数讯息，找到往后再拿出算盘计划，末了再将效果写回到账本上。
同样在MySQL中要是每一次的革新职掌都需求写进磁盘，尔后磁盘也要找到对应的那笔纪录，尔后再革新，周全经过IO成本、搜索成本都很高。而粉板和账本合做的周全经过便是MySQL用到的是Write-AheadLogging技巧，它的关键点便是先写日记，再写磁盘。此时账本=BinLog，粉板=RedoLog。
1、纪录革新时，InnoDB引擎就会先把纪录写到RedoLog（粉板）内部，并革新内存。同时，InnoDB引擎会在空隙时将这个职掌纪录革新到磁盘内部。
2、要是革新太多RedoLog解决不了的时辰，需先将RedoLog部份数据写到磁盘，尔后擦除RedoLog部份数据。RedoLog好似转盘。
RedoLog有writepos跟checkpoint
writepos：是暂时纪录的场所，一边写一边后移，写到第3号文献结尾后就回到0号文献发轫。
checkpoint：是暂时要擦除的场所，也是此后推移而且轮回的，擦除纪录前要把纪录革新到数据文献。
writepos和checkpoint之间的是粉板上还空着的部份，也许用来纪录新的职掌。要是writepos追上checkpoint，示意粉板满了，这时辰不能再实行新的革新，得停下来先擦掉一些纪录，把checkpoint促成一下。
有了redolog，InnoDB就也许保证尽管数据库产生反常重启，以前提交的纪录都不会丧失，这个本领称为crash-safe。redolog两阶段提交：为了让binlog跟redolog两份日记之间的逻辑一致。提交过程大抵下列：
1prepare阶段--2写binlog--3