一、从查询语句的执行过程来看MySQL架构
从一条语句的执行过程来窥探MySQL的架构，MySQL从架构上可以分为Server层和存储层。Server层有连接器、查询缓存、分析器、优化器和执行器。存储层是以插件形式存在的，在建表的时候选择存储引擎，默认是innoDB。
连接器：SQL语句的执行需要先获取连接，指定ip+port+user+password，然后MySQL通过检验之后就获得一条连接，后面查询的内存管理都在这个连接上。连接分为长连接和短连接，长连接是指客户端如果持续有请求，那么继续复用相同的连接。而短连接是指执行几次查询之后就断开连接，下次重新连接。由于连接是比较复杂的过程，建议使用长连接，但是长连接会带来内存暴涨的问题，可能会被kill掉，现象就是MySQL突然断开。这种情况下可以定时断开长连接，获取执行完比较消耗内存的查询之后，主动断开连接或者reset连接。
查询缓存；MySQL的查询缓存是比较鸡肋的，因为当表更新之后，该表的查询缓存会失效。因此很少能命中查询缓存。除非是更新少，读取多的配置表。MySQL8.0以后已经废弃了查询缓存
分析器：分析器进行词法分析和语法分析。词法分析解析SQL语句，生成一个个单词，判断输入的单词是否正确，比如说select 、from等词是否输入正确，不符合的话会报错。然后生成的单词进一步生成语法树，判断整个语句是否符合MySQL的语法，不符合的话也会报错。
优化器：这个阶段是分析SQL语句如何执行更优。包括使用哪个索引，join的顺序等
执行器：执行器首先判断用户是否有该表的权限，如果有的话就去存储引擎取数据，判断是否符合，符合的话放入结果集，然后继续去存储引擎取下一行，重复上述过程，一直到取到最后一行，最后再把结果集返回给客户端。那么这条语句就到此完成了。
二、从SQL更新过程理解redo log和binlog
SQL语句的更新过程总体上和查询过程一致，都是先建立连接，分析器进行语法、语法分析，优化器选择索引，执行器调用引擎层的接口更新语句。具体不同的地方如下：
redo log是引擎层的日志，用于MySQL的case-safe，数据在写入时，不会直接写入磁盘（性能太差），而是先写到redo log，然后不同的机制会再刷入磁盘。如果MySQL突然崩溃，可以从redo log进行恢复，redo log记录的是具体在哪个数据页更新了什么内容。采用循环写机制，有一个check-point将redo log刷新到磁盘，write pos是写入指针，两个指针相遇的时候就需要check point将redo log刷新到磁盘，才能继续写入
binlog是归档日志，也就是说MySQL恢复或者主从备份依赖的日志。当MySQL扩容的时候，先拿出全量备份，可能是一周前的备份，然后从备份的那个时间点之后应用binlog日志。（这里先记一个todo，主从备份的详细过程待了解）binlog日志是追加写的，也就是写满了会申请一个新的日志而不会覆盖。
那么为什么需要两阶段提交呢？我的理解是binlog在Server层、redo log在引擎层，这两个日志的作用各不相同，这两个日志要保证一致性的话就需要用到分布式的两段式提交了。具体就是如上图
update T set c=c+1 where ID=2;
执行器调用引擎层获取ID=2那一行，引擎层先看内存buffer pool有没有，有的话直接返回，否则要去磁盘获取加载到内存中。然后执行器更新ID=3，调用引擎层写入，引擎层先将新行写入内存，然后写入redo log此时这个事务处于prepare状态，然后执行器写入binlog，再调用引擎层将事务提交，对应的redo log commit。这样就能保证崩溃的时候无论处于哪一个状态，要么事务回滚或者提交成功，binlog和redo log能保持一致，进而保证后续恢复临时库或者扩容的时候，能保值主从一致性
三、事务的隔离性
事务有四大特性：原子性、隔离性、持久性和一致性。隔离性是指事物之间的隔离程度。MySQL的隔离性有读未提交、读提交、可重复读和串行化。
- 读未提交，一个事务修改了一行，还没等提交，另一个事务就能看到了，这就是脏读了。这种隔离性是最低的
- 读提交：一个事务a修改了一行，如果该事务还没提交，其他事务b是不可见的，提交之后就可见了。解决了脏读的问题，但是在事务a提交前后的值是变化的，在事务b看来同样的读取某一行，值发生了变化，那么就造成了不可重复读?；够嵩斐苫枚?，假设事务a插入一行数据，或者删除一行数据，那么在事务b看来前后数量发生了变化，这就是幻读。不可重复读是由于update和delete产生的不一致，而幻读主要是由于insert产生的不一致。
- 可重复读：可重复读保证在一个事务中多次读取的结果是一致的。MySQL在这种隔离级别下解决了不可重复读和幻读的问题
-
串行化：读加读锁，写加写锁，遇到锁冲突就等待
那么事务的隔离性是如何实现的呢？
对读未提交来说，只需要返回最新值即可；对于串行化是利用加锁来进行隔离；对于读提交和可重复读来说是通过read view来实现的。读提交会在每个SQL语句执行的时候生成一个视图，而重复读则是事务启动的时候。以可重复读为例：
image.png
如图，一条记录从1,2,3最后变为4，在每个事务中产生了不同的视图，通过回滚日志，（从当前值如果回滚到之前版本的日志）来得到不同版本，同样的一条记录存在多个不同版本，这就是数据库的MVCC机制。MySQL就是通过不同的视图实现了事务的隔离性，然后在当没有比当前回滚日志更早的视图之后，日志才能被回收。比如说如果A视图还存在，那么将3改为2这个回滚日志就不能被回收。所以尽量不要使用长事务，因为事务用到的回滚段难以回收，占有较大的存储空间。
