Undo Log
回滚日志,用于将数据回滚到之前的状态。
MySQL在进行数据的增、删、改时,会将数据写入到Undo Log日志中。
对于Undo Log存在着insert和update两种类型的数据。插入语句对应的是insert类型,修改、删除语句对应的是update类型。
Undo Log以段的方式管理和记录日志信息,在Innodb存储引擎的数据文件中,包含一种叫rollback segment的回滚段,每个段内部包含了1024个undo log senment。
-
Undo Log实现了事务的原子性
- 通过Undo Log可以将数据恢复到修改的前的版本,以实现事务的原子性
-
MVCC事务多版本控制也是通过Undo Log日志实现的
- 在innodb存储引擎中创建的表,每行数据都记录着三个隐藏的字段,DB_TRC_ID、DB_ROLL_PTR、DB_ROW_ID。
- 在一个事务当中对数据进行修改时,Undo Log日志中的数据会根据DB_TRC_ID、DB_ROLL_PTR形成一个链表
- 通过当前事务的ID以及Redo Log中根据当前事务生成的链表,实现了多版本并发控制。
-
Undo Log日志在事务提交后并不会立刻删除,会通过一个后台purge线程进行处理。
Redo Log
重做日志,对于数据的增、删、改操作,在buffer中完成数据的修改后,并不会即时将数据写入磁盘。而是会将修改操作以顺序循环的方式写入到Redo Log中。
- 频繁写入磁盘会消耗很多的时间,降低响应速度
- 写入磁盘时并不是顺序写入,需要找到需要写入的位置在进行写入。
- Redo Log日志是顺序写入的,不用找到磁盘中的具体位置后再写入。
- Redo Log日志也不是即时持久化的。
- 每秒执行一次持久化
- 每次事务提交时执行一个持久化
- 每次事务提交时,从Redo Buffer缓存中放到系统缓存中,在每秒刷新一下缓存。默认使用该机制。可以保证MySQL服务挂机不丢失数据,系统挂机最多就是1S数据。
Bin Log
记录MySQL数据库表机构一级数据修改的二进制日志。日志格式是以时间形式记录,同时记录了语句的消耗时间。
- 可用于主从复制
- 通过mysqlbinlog等日志进行数据恢复。
文件记录模式
Binlog文件记录模式有STATEMENT、ROW和MIXED三种。
- ROW:记录每一行的修改情况,修改记录会非常清晰,但会产生大量的日志
- STATEMENT:记录SQL语句,日志量小,同步快,但对于一些函数操作,比如date()获取时间的,会不一致。
- MIXED:STATEMENT、ROW的混合模式,一般使用STATEMENT模式,但对于无法完全复制的操作会使用ROW模式。
MVCC
todo
其它
MySQL的每行数据,除了明确定义的字段外,还会存在三个隐藏的字段。
隐藏字段 | 字段含义 |
---|---|
DB_TRC_ID | 用于记录最后一个修改/插入过记录的事务ID |
DB_ROLL_PTR | 回滚指针,指向记录的上一个版本 |
DB_ROW_ID | 隐藏的自增ID,表没有指定ID时,会使用该字段作为自增ID |