一条sql语句的执行过程
一条select语句执行流程
第一步：连接器
连接器负责跟客户端建立连接、获取权限、维持和管理连接。如果用户名密码验证通过后，连接器会到权限表里面查出你拥有的权限。之后该连接的权限验证都依赖于刚查出来的权限。
第二步：查询缓存
当获取连接后，一条SELECT语句会先去查询缓存，看之前是否执行过。如果获取到缓存后就执行返回，不然继续后面的步骤。
大多数时候不建议使用缓存，因为只要一个表更新，这个表上的所有缓存数据就会被清空了。对于那些经常更新的表来说，缓存命中率很低。MYSQL8版本直接将查询缓存的整块功能删掉了。
第三步：分析器
分析器首先会做“词法分析”，MYSQL会识别出SQL语句里面的字符串是什么以及代表什么。接下来就是“语法分析器”，分析SQL的语法问题。
第四步：优化器
优化器会对SQL的执行顺序，使用哪个索引进行优化。确定SQL的执行方案。
第五步：执行器
执行器执行SQL语句会对权限进行校验，如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。
一条update语句执行流程
update语句除了会执行上面的五步，还会涉及两个重要的日志模块。
两个重要的日志模块
redo log （重做日志）
redo log 是innodb所特有的，当有一条更新语句时，innoDB引擎会先把记录写到redo log中，然后更新内存，这时候更新就算完成了。innoDB会在合适的时候将这个记录更新到磁盘中去。
特点：redo log 是固定大小的，属于循环写。redo log是物理日志，记录的是“在某个数据页上做了什么修改”。有了redo log ，InnoDB可以保证数据库发生异常重启的时候，之前提交的记录不会丢失，这个能力为crash-safe。
binlog（归档日志）
binlog属于server层的日志，是逻辑日志，记录的是这个语句的原始逻辑，比如给“id =1 的一行的某个字段+2”。binlog是追加写入的，binlog写到一定的大小后切换到下一个，不会覆盖之前的。
更新语句的内部流程
update t set n = n+2 where id =1
- 执行器先找引擎找到id=1的那一行，如果这一行的数据页已经在内存中则直接返回给执行器。否则先从磁盘读入内存中，然后在返回。
- 执行器拿到了引擎返回的数据行，把这个n值+1，得到新的行数据，然后调引擎的接口写入这行新数据。
- 引擎将这行数据更新到内存中，同时将这个更新操作记录到redo log里，此时rodo log属于prepare状态。然后告知执行器执行完成了，随时可以提交事务了。
- 执行器生成这个操作的binlog，并把binlog写入磁盘。
- 执行器调引擎的提交事务接口，引擎把刚刚写入的redo log的状态改为commit状态，更新完成。
两段式提交
redo log的写入分为两部分，是为了保证这两份日志的逻辑一致。
相关配置
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1，表示每次事务的 redo log 都直接持久化到磁盘。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。
