站长网站建设磁力搜索
目录
1 一条sql写语句的执行过程
2 bin log变更日志
(1) 日志格式
(2) 使用缓冲区
(3) 相关参数
3 redo log重做日志
(1) 预写日志
(2) 刷盘策略
4 bin log 与 redo log 的区别
5 undo log撤销日志
(1) MVCC多版本并发控制
(2) 使用缓冲区
1 一条sql写语句的执行过程
可以看出，sql 的写流程中用到了三种日志：undo log、redo log 和 bin log。
2 bin log变更日志
也称为二进制日志。
mysql 会记录数据库变更（INSERT/UPDATE/DELETE）过程中所有表结构的变化到 bin log。用于主从复制和数据恢复。
bin log 是独立于存储引擎的，也就是不论使用什么引擎，都要记录 bin log 日志。
(1) 日志格式
bin log 本地文件使用的是追加写的方式。可能有多个日志文件。
查询所有日志文件：
SHOW BINARY LOGS;日志格式有三种：
- Statement: 基于语句复制
- Row: 基于行复制（默认值）
- Mixed: Statement 与 Row 混合（默认使用 Statement，涉及日期、函数相关时用 Row）
可以查询日志格式：
SHOW VARIABLES LIKE 'binlog_format’;(2) 使用缓冲区
写 bin log 时，会先写到缓冲区中，再由后台线程去刷盘。bin log 有自己独立的日志缓冲区，mysql 会给每一个工作线程分配一个 bin log 的缓冲区，名为 bin_log_buffer。
查询 bin log 的刷盘策略：
SHOW VARIABLES LIKE 'sync_binlog';有三种配置：
- 0 - 不主动刷盘，由操作系统决定何时刷盘（安全性差，数据易丢失）
- 1 - 每次提交事务时刷盘（安全性高，性能差）（默认值）
- N - 每N次提交后刷盘（平衡安全性和性能）
(3) 相关参数
以下参数都可以使用 SHOW VARIABLES LIKE ‘xxx' 命令查询：
- log_bin：是否开启bin-log，默认ON
- log_bin_basename：存储目录和文件名前缀，默认./bin.0000x
- log_bin_index：索引文件的存储位置（因为本地有多个日志文件，需要用索引来确定目前该操作的日志文件）
- binlog_format：存储方式（Statment/Row/Mixed）
- max_binlog_size：本地单个文件的最大限制，最大 1GB
- binlog_cache_size：为每条线程的工作内存分配的缓冲区大小
- sync_binlog：刷盘频率
- binlog_do_db：设置后，只会收集指定库的bin-log日志
3 redo log重做日志
记录了所有对 InnoDB 表的数据页所做的物理更改。
用于保证事务的持久性和崩溃恢复，同时还可以提高写入性能。
redo log 是 InnoDB 引擎独有的。
(1) 预写日志
实际操作写入数据时，先写到内存中，然后由后台线程再刷写到磁盘，以提高写入性能。但是这也会导致机器异常、宕机时，内存中的数据尚未刷写到磁盘，造成数据丢失。
因此 redo log 使用了预写日志的机制，在向内存写如数据之前，会先写一条状态为 prepare 的 redo log，等待 bin log 写入数据完成后，再更新这条日志状态为 commit。
这样 mysql 崩溃时，就可以通过 redo log 来恢复，保证数据不丢失：
- 如果在 redo log(prepare) 前崩溃：此时事务还未提交，不会影响一致性
- 如果在 bin log 写入前崩溃：重启后根据 redo log 中的事务 ID，回滚前面已写入的数据
- 如果在 redo log(commit) 前崩溃：由于 bin log 已经写入成功，所以从机也可以同步数据，因此重启时直接再次提交事务，写入一条redo(commit)即可
(2) 刷盘策略
redo log 不是直接写到磁盘中的，也是先写到内存再刷到磁盘，其写入的内存缓冲区名为 redo_log_buffer。
查询 redo log 的刷盘策略：
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';有三种配置：
- 0 - 每秒刷一次盘
- 1 - 每次提交事务时刷盘（安全性高，性能差）（默认值）
- 2 - 不主动刷盘，由操作系统决定何时刷盘（安全性差，数据易丢失）
mysql 默认使用第二级刷盘方式，也就是每次提交事务时都会刷盘，这也就意味着一个事务执行成功后，相应的 redo log 日志一定会被刷写到磁盘中，无需担心会出现丢失风险。
redo log 在本地磁盘中使用两个文件，将两个组成一个环形，通过两个文件互相擦写的方式记录日志。
4 bin log 与 redo log 的区别
| bin log | redo log | |
| 功能 | 记录数据库的所有变更操作 | 记录 InnoDB 表的数据页物理修改 |
| 主要用途 | 主从复制，用于保证多节点间数据一致性 | 崩溃恢复，用于保证数据在单节点上不丢失 |
| 作用范围 | Server 层 | InnoDB 存储引擎层 |
| 日志格式 | Statement, Row, Mixed | 物理日志 |
| 写入方式 | 追加写 | 两个文件循环写 |
5 undo log撤销日志
也称为回滚日志。InnoDB 会为每行记录设置一个回滚指针 roll_ptr，指向此行上次修改前的数据，形成一个单向链表（undo 版本链）。
undo log 用于实现事务回滚、MVCC 版本控制。
undo log 也是 InnoDB 引擎独有的。
(1) MVCC多版本并发控制
InnoDB 会为每一行添加几个隐藏列：
- 事务ID
- 回滚指针，指向 undo log 的指针
- 删除 flag，标记此行是否被删除
在写入操作之前，会先将旧的行记录到 copy 到 undo log 中（xx.ibdata 文件），然后将 roll_ptr 指针指向这条 undo log 记录，再去实际更新行记录。
那么查询时，只查询 事务ID <= 当前事务ID 的数据，利用乐观锁机制，实现多个事务并发读写。
(2) 使用缓冲区
undo log 不是直接写到磁盘文件中的，也是先写到内存，再由后台线程刷到磁盘，其写入的内存缓冲区名为 undo_log_buffer。
并且当事务提交后，undo 中的记录也不会立即被删除（可能还有其他事务在读取），而是有一个专门的 purger 线程，处理不再使用的 undo log 将其清理。