MySQL进阶系列：一条sql是怎么执行的

本文是在存储引擎是InnoDB的前提下

mysql中的针对表的操作可以分为增删改查四种操作，也就是常说的crud大法，根据类型分为DML(增删改)和DQL(查)；今天就说下插入和查询的语句时如何在mysql中执行的。

不管是DML还是DQL都是要经过连接器，缓存，分析器，优化器，执行器调用存储引擎的API。在前四个阶段都是一样的流程，具体的可以参考 mysql基础架构篇，文章中有详细简介各个模块的作用，本文就不展开说了，后面我们详细说说执行器在存储引擎上是怎么查询和修改(删除/新增)的。

小知识：

扇区：磁盘存储的最小单位，扇区一般大小为512Byte。

磁盘块：文件系统与磁盘交互的的最小单位（计算机系统读写磁盘的最小单位），一个磁盘块由连续几个（2^n）扇区组成，块一般大小一般为4KB。

mysql的页：mysql中和磁盘交互的最小单位称为页，默认大小是16kb,也就是4个磁盘块。也就是说mysql在进行数据读取的是默认情况下一次就是读取16kb(可以修改)，即是我只查询一条大小只有1kb的数据，mysql读取的也是16kb。

一条查询语句是怎么执行的

select查询比较简单，其实就是到硬盘上按照页(16kb)把数据加载到内存，然后再去匹配where条件，找出符合条件的数据；

如果where条件没有索引，那么就是全表扫描，遍历所有的数据页到内存，然后一个个匹配。
如果where条件是主键索引，那么就会把主键索引的数据页加载到内存，然后匹配到具体的行数据返回；
如果where条件是普通索引，那么就会把普通索引的数据页加载到内存，然后匹配到符合条件的叶子结点(B+树的叶子结点)，如果能够使用覆盖索引，那么就会直接返回，如果不能使用覆盖索引，则会进行回表查询(走一次主键索引查询)。覆盖索引和回表不清楚的可以参考历史文章：需要知道的索引基础知识

一个更新语句是怎么执行的

更新语句首先要按照查询的流程执行，因为肯定要先知道是哪条记录，之后才能去更新这条记录。之后就是更新了，更新操作涉及到几个日志的记录，分别是undolog(InnoDB的回滚日志) ，redolog(InnoDB的数据持久化日志)，binlog(mysql server的归档日志)，下面我们看下他们之间是怎么配合完成数据更新的。

首先执行引擎按照条件找数据，如果内存中存在则直接返回，不存在查询后返回。
把查询出来的这条记录先放到undolog中，用于更新失败数据回滚，具体的使用可以参考上一篇文章mvcc
执行器调用存储引擎接口写入数据，在缓存池中修改这条记录，。
写redo日志，先把数据更新到redo日志的缓存中。
准备提交事务，把redo日志缓存刷入磁盘。这时候redolog 是prepare阶段(共有两个阶段prepare和commit)，然后通知执行器完成。
执行器开始执行binlog写入磁盘。
然后调用存储引擎的事务提交接口，把redolog中的prepare改成commit状态，至此更新完成。
之后有IO线程以页为单位随机写入磁盘，把我们更新后的数据慢慢落入磁盘中。

两个日志是分开写的，所以很难保证两个日志数据一致，在恢复的时候尽量保证同时参考两个日志文件，如果一致才会提交，不一致丢弃。

假如在步骤8的时候更新失败，两种情况

sql执行失败，这时候使用undolog中记录的历史数据进行恢复即可。
断电或者进程重启，那么就会在下次重启的时候判断redolog是否是commit状态，如果是可以直接提交写入磁盘，如果不是commit状态，就会判断binlog是否完整(两阶段提交保证数据的一致性)，如果完整那么数据有效，写入磁盘；如果不完整或者只有一个日志存在记录，直接丢弃即可。

我们要更新的数据是存在磁盘的任意位置，是属于随机IO，效率是很低的，这样mysql的并发无法保证，而redo日志和binlog属于预写日志，都是顺序IO，直接写入即可，效率要高很多，即是失败了也可以根据日志恢复。