0%
SQL执行过程
- 客户端 -> 连接器 -> 分析器 -> 优化器 -> 执行器
- 连接器
- 管理连接，权限验证，维持管理连接
- 分析器
- 词法分析，语法分析
- 优化器
- 执行计划生成，索引选择
- 执行器
- 操作引擎，返回结果
- 存储引擎
- 存储数据，提供读写接口
- 连接器会优先查询缓存，如果命中则直接返回结果
连接器
- 连接器负责跟客户端建立连接、获取权限、维持和管理连接。
查询缓存
- 大多数情况下不要使用查询缓存
- 查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。
分析器
优化器
- 优化器是在表里面有多个索引的时候，决定使用哪个索引
- 在一个语句有多表关联（join）的时候，决定各个表的连接顺序。
执行器
- 执行之前会进行权限校验
- 根据表的引擎定义，使用引擎提供的接口
- 获取记录集作为结果返回给客户端。
MySQL日志模块
redo log （重做日志）
- WAL （Write-Ahead Logging）
- 核心先写日志，在写磁盘
- 保证及时数据库发生异常重启，之前提交的记录不会丢失（crash-safe）
- InnoDB特有
binlog （归档日志）
对比
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
- redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
两阶段提交
- 引擎讲更新操作记录到redo log中，此时redo log处于prepare状态，同时告知执行器执行完成，可以提交事务。
- 执行器生成该操作的binlog并写入磁盘。
- 执行器调用引擎提交事务接口，引擎讲刚刚写入的redo log改为提交commit状态。
- redo log的写入拆成了2个步骤prepare和commit，即两阶段提交。
先写rodo log 后写binlog问题
- 写完rodo log 后，binlog未写完，重启后，主库可以通过redo log恢复，但是通过binlog恢复临时库会丢失该次更新。
先写binlog 后写redo log问题
- 写完binlog后未写redo log，重启后由于redo log没写，即该次事务无效，而binlog中已经包含，则用binlog恢复会多出来一个事务。