MySQL的基础架构

MySQL的基本架构示意图

我们来看看MySQL内部有哪些零件，当我们碰到问题的时候，这张架构图能够帮助我们快速的定位并解决问题。

MySQL分为Server层和存储引擎层。他们分别的功能如下：
Server层：涵盖了MySQL的大多数核心服务功能，以及所有的内置函数，所有跨存储引擎的功能都在这一层实现，如存储过程，触发器，视图等
存储引擎层：负责数据的存储和提取，他是插件式的，支持多个存储引擎

一条查询语句的执行流程

1. 连接到这个数据库，这时连接器负责和客户端建立连接，获取权限，维持和管理连接

mysql -h主机地址 -u用户名 －p用户密码

完成经典的TCP握手之后，连接器要开始认证身份，这个时候要输入用户名和密码
如果用户名或密码不对，你就会收到一个"Access denied for user"的错误
如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。
这也就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限作了修改，也不会影响已经存在连接的权限，如果客户端太长时间没有动静，连接器就会自动将他断开。
在连接数据库的时候我们尽量减少建立连接的动作，也就是尽量使用长连接。但是如果全部使用长连接，我们可能会发现，有时候MySQL内存会涨的很快，因为长连接会累积下来，解决这个问题可以考虑以下方案：

 1. 定期断开长连接
 2. 如果使用的MySQL或更新版本，可以在每次执行一个比较大的操作后，通过执行mysql_reset_connection来重新初始化连接资源，这个过程不需要重连和中心做权限验证，但是会讲连接恢复到刚刚创建完时的状态

2. 连接建立完成后，就可以执行查询语句了，执行逻辑来到查询缓存这里，我们会先到查询缓存里面看看我们之前是不是执行过这条语句，在查询缓存中，它是以key-value的方式进行存储的，key是查询的语句，value是查询的结果。
   但大多数情况，建议不要使用查询缓存，因为查询缓存的实效很频繁，只要有有对一个表的更新，这个表的所有查询缓存都会被清空，除非业务中就是有一张静态表，很长时间才会更新一次，比如，一个系统配置表
   需要注意的是，MySQL8.0版本直接将查询缓存的整块功能删掉了，也就是说8.0开始彻底没有这个功能了。
3. 分析器
   分析器会先做“词法分析”，识别出里面的字符串分别是什么，代表什么，然后做语法分析，然后语法分析器会根据语法规则，判断这个SQL语句是否满足MySQL的语法，如果语句不对就会收到You have an error in your SQL syntax”的错误提醒
4. 优化器
   经过了分析器，MySQL就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。
5. 执行器
   执行器会首先判断一下你对这个表有没有执行查询的权限，如果没有就会返回没有权限的错误，如果有权限，就打开表继续执行。打开表的时候，执行器会根据表的引擎定义，去使用这个引擎提供的接口

一条更新语句的执行流程

假设我们有这么一条更新语句

update T set c=c+1 where ID=2;

更新语句的流程和查询语句的流程差不多，先连接数据库，然后会把这个表的查询缓存给清空一下。接下来，分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用ID这个索引。然后，执行器负责具体执行，找到这一行，然后更新。
与查询流程不一样的是，更新流程还涉及两个重要的日志模块（redo log 重做日志）和（bin log 归档日志）

redo log

我们想一想这个问题，如果每次更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本，查找成本都很高，于是MySQL用redo log帮我们解决了这个问题，其实就是WAL技术（write Ahead Logging），他的关键点就是先写日志，再写磁盘
具体来说，就是有一条记录需要更新的时候，InnoDB引擎会先把记录写到redo log里，并更新内存。在适当的时候，InnoDB引擎将这个操作记录更新到磁盘里面，这个更新往往是在系统比较空闲的时候做的。
但是InnoDB的redo log是固定大小的，当记录在redo log的更新操作不多时，InnoDB可以在空闲的时候处理，但是redo log如果快写满了，这个时候InnoDB就要停下当前的工作，先把redo log的记录更新到磁盘中，然后把更新完的操作在redo log上擦掉。为新的更新操作腾出空间
有了redo log ，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力被称为crash-safe

binlog

上面我们所讲的redo log是InnoDB引擎所特有的，而server层也有自己的日志，称为bin log（归档日志）
关于redo log 和 bin log 的不同

1. redo log 是InnoDB特有的；bin log 是server层实现的，所有引擎都可以用
2. redo log 记录的是在某个数据页上做了什么操作；bin log，记录的是这个语句的原始逻辑，比如：”给ID=2”这一行的c字段加1
3. redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

接下来，我们就可以看看InnoDB引擎在执行这个简单的update语句时的内部流程，

1. 执行器先找引擎取ID=2这行。ID是主键，引擎通过树找到这行。如果ID=2这行所在数据页本来就在内存，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把值加1，再调用引擎接口写入这行新数据。
3. 引擎将这行数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成，随时可以提交事务
4. 执行器生成这个操作的bin log，并把binlog写入磁盘
5. 执行器条用引擎提交事务的接口，引擎把刚刚写入的redo log改成提交（commit）状态，更新完毕

我们观察最后三步，将redo log 的写入拆成了两个步骤：prepare 和 commit ，这就是两阶段提交

两阶段提交

两阶段提交这是为了让两份日志之间的逻辑一致。
接下来我们思考怎么让数据库恢复到以前某个时间的任意一秒的状态呢？
binlog 会记录所有的逻辑操作，那么备份系统中一定会保存最近半个月的所有binlog，同时系统会定期的做整库备份。当需要恢复到指定的某一时刻时：

1. 首先找到最近的一次全量备份
2. 然后从备份的时间点开始，将备份的binlog依次取出来，重放到我们需要恢复到的那个时刻

说完恢复数据过程，我们再思考一下为什么日志需要“两阶段提交”呢？
我们这里用反证法解释一下，如果没有两阶段提交，那么就只有两种情况，要么先写redo log要么先写binlog，我们看看这两种方式有什么问题：

1. 先写redo log再写binlog
   假设我们把一个字段的值从0改为1，在写完redo log还没有写binlog的时候，MySQL发生了异常重启，此时因为有redo log的存在，这个字段值更改为1，MySQL是知道的，但是binlog并没有记录，当下次我们用binlog来恢复数据的时候，恢复的数据就会少了更新这个操作，与原库值不符
2. 先写binlog再写redo log
   假设我们把一个字段的值从0改为1，在写完binlog还没有写redolog的时候，MySQL发生了异常重启，此时redo log并没有记录下这个更新操作，这个事务无效，所以这个字段的值还是0，但是当我们用binlog恢复数据的时候，就会多一个事务，恢复出来的这个字段就变成1了，与原库值不符合