写在最前
这是读书笔记，Mysql，innodb系列一共3篇。
ACID
- A：原子性，要么成功，要么失败
- C：一致性，事务将数据库从一种状态转换为另一种稳定状态，不违反约束条件
- I：隔离性，多个事务互不影响
- D：持久性
事务的隔离级别
| 隔离级别 |
说明 |
| READ UNCOMMITTED |
未提交读，会造成脏读，违反持久性D |
| READ COMMITTED |
读已提交数据， 会造成幻读 违反一致性C |
| REPEATABLE READ |
可重复读，默认隔离级别 |
| SERIALIZABLE |
不会使用mysql的mvcc机制，而是在每一个select请求下获得读锁，在每一个update操作下尝试获得写锁 |
SELECT@@global.tx_isolation查看全局事务隔离级别
事务的实现
Force Log at Commit机制
- 当事务提交时，必须先将该事务的所有日志写入到日志文件进行持久化，之后进行COMMIT操作完成。
- 日志写入日志文件时，日志缓冲先写入文件系统缓存，为了确保写入磁盘，需要调用一次fsync操作。
- 由于fsync的效率取决于磁盘的性能，因此磁盘的性能决定了事务提交的性能，也就是数据库的性能。
3种日志文件
redolog
概念
实现事务的持久性。
InnoDB存储引擎层产生，物理日志，记录的是对页的修改，innodb1.2版本后，最大512GB
一个事务多个日志记录，每个事务内部是顺序写的。并发写入多个事务的日志，不随事务提交顺序写入
两部分：重做日志缓冲（redo log buffer）易失的；重做日志文件（redo log file），持久的
log buffer刷新策略
由innodb_flush_log_at_trx_commit控制
| innodb_flush_log_at_trx_commit值 |
说明 |
| 0 |
提交时，不写入日志文件 |
| 1 |
默认值，提交时调用一次fsync操作 |
| 2 |
提交时写日志文件，不进行fsync操作 |
log buffer刷新到磁盘的规则
- 事务提交时
- log buffer已经有一半空间被使用
- log checkpoint时
innodb恢复时如何使用redolog
checkpoint存储了已经刷新到磁盘页上的LSN，所以仅需恢复checkpoint开始的日志部分
innodb，顺序读取，并行操作，提高性能
物理日志，幂等的，恢复快
LSN存储了checkpoint的位置。
undolog
基本概念
- 存储在undo段中，位于共享表空间，逻辑日志
- 支持mvcc，支持回滚
- undolog 会生产redo log
回滚时，undo生产反向操作，insert对应delete，delete对应一条insert，update对应一个反向update
格式
| 类型 |
说明 |
| insert undo log |
insert产生，事务本身可见，其他事务不可见，commit后直接删除 |
| update undo log |
delete，update产生，其他事务可见，commit后放入列表中，供purge操作
比insert undo log大
|
commit后
undo加入history list中，供后续purge操作
判断undo页 的使用空间是否小于3/4,是新的undo log 记录到老的undo log后边
binlog
MySQL数据库的上层产生的，并且二进制日志不仅仅针对于InnoDB存储引擎，
逻辑日志，记录的是SQL语句
事务提交后一次性写入
purge
purge是清理的delete和update之前行记录的版本。
从history list中找undo log，然后再从undo page中找undo log，防止大量随机读写，提高性能
相关参数
：
innodb_purge_batch_size设置每次需要purge清理的undo page数量，innodb1.2以后默认为300
innodb_max_purge_lag用来控制history list的长度，默认值为0，不做任何限制
大于0，延后DML操作，对每行数据延缓：
delay=((length(history_list)- innodb_max_purge_lag)*10)-5
group commit
提高磁盘fsync的效率,一次刷新多个事务日志文件
综述：5.7版本innodb开启binlog的commit过程
![]()
注意：
THD是MySQL server层最核心的类
LSN：
日志序列号
重做日志写入的总量
checkpoint的位置
页的版本
