01 MySQL整体架构

4.1 写redo log

page cache

负责数据的存储和提取

一条更新语句是如何执行的：update users set name='xxx' where id=101. 加载数据到 buffer pool（同时会对数据加锁）2. 记录 undo log 日志用于回滚3. 更新 buffer pool 中的数据（脏页）4. redo log buffer5. 准备提交事务的时候 redo log buffer 刷盘（根据刷盘策略）6. 写 binlog 日志（根据binlog刷盘策略刷盘）7. 后台线程刷脏页

redo log 日志文件

binlog cache

执行器

和客户端建立连接、获取权限、维持和管理连接

server层

存储引擎

1.调用存储引擎接口

myisam

连接器

binlog 的三种格式：statement、row、mixed。查看binlog的格式：show variables like '%binlog_format%';查看binlog内容：show binlog events in 'master.000001'; 设置binlog格式：set global binlog_format='STATEMENT';binlog_format=statement 时，binlog 里面记录的就是 SQL 语句的原文。delete from t where a>=4 and t_modified<='2018-11-10' limit 1;注意：binlog 设置的是 statement 格式，并且语句中有 limit，这个命令可能是 unsafe 的binlog_format 使用 row 格式的时候，binlog 里面记录了真实删除行的主键 id，这样 binlog 传到备库去的时候，就肯定会删除 id=4 的行，不会有主备删除不同行的问题。redolog刷盘策略：innodb_flush_log_at_trx_commit0 每秒提交redo buffer 到 os cache 并强制刷盘。1 事务提交时提交Redo buffer 到 os cache 并刷盘2 事务提交时提交Redo buffer 到 os cache 并每秒刷盘没有提交的事务的 redo log 也可能会写入到磁盘中：1.InnoDB 有一个后台线程，每隔 1 秒，就会把 redo log buffer 中的日志，调用 write 写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。2.redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时候，后台线程会主动写盘。3.并行的事务提交的时候，顺带将这个事务的 redo log buffer 持久化到磁盘。如果把 innodb_flush_log_at_trx_commit 设置成 1，那么 redo log 在 prepare 阶段就要持久化一次，因为崩溃恢复逻辑是要依赖于 prepare 的 redo log，再加上 binlog 来恢复的。建议redo日志刷盘策略设置为1，保证事务提交之后，数据绝对不能丢失。binlog刷盘策略：sync_binlog0 只提交到 os cache，不主动刷盘1 每次事务提交刷盘N N个事务提交，刷盘一次系统给 binlog cache 分配了一片内存，每个线程一个，参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，会暂存到磁盘。事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 中，并清空 binlog cache。binlog 是不能被拆开的，不论这个事务多大，也要确保一次性写入。

undo log日志文件

对 SQL 语句做解析

bin log 日志文件

7 写入binlog文件与位置写commit标记

分析器

根据执行计划，调用存储引擎接口获取/更新数据

xx.idb

3.1生成 undo log

操作系统线程刷新到磁盘

5 根据刷盘策略进行刷盘

4.2写bin log

……

查询最优路径

2.1 加载数据到 page cache

解析sql

6 准备提交事务根据刷盘策略进行刷盘

执行计划

2.2 加载数据到buffer pool

innodb

优化器

生成执行计划，索引选择

buffer poolfree、flush、LRU……

3.2 更新内存数据

innodb存储引擎

redolog buffer