Mysql日志全解
文章目录
Mysql日志类型
- redo-log
- undo-log
- bin-log
- error-log
- slow-query-log
- general-log
- relay-log
redo-log 重做日志
作用
确保事务的持久性
redo日志记录事务执行后的状态，用来恢复未写入data file的已成功事务更新的数据。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
内容
物理格式的日志，记录的是物理数据页面的修改的信息，是顺序写入redo log file的物理文件中去的。
什么时候产生
事务开始之后就产生redo log
什么时候落盘
redolog的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。
什么时候释放
当对应事务的脏页写入到磁盘之后，重做日志占用的空间就可以重用（被覆盖）。
对应的物理文件
默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1 lb_logfile2
参数配置
| 配置项 | 配置内容 | 默认 |
|---|---|---|
| innodb_log_group_home_dir | 指定日志文件组所在的路径。 | ./ |
| innodb_log_group_home_dir | 指定重做日志文件组中文件的数量 | 2 |
| innodb_log_file_size | 重做日志文件的大小。 | 134217728 |
| innodb_mirrored_log_groups | 指定了日志镜像文件组的数量 | 1 |
脏页
InnoDB 有 buffer pool（简称bp）。bp 是 物理页 的缓存，对 InnoDB 的任何修改操作都会首先在 bp 的 page 上进行，然后这样的页面将被标记为 dirty 并被放到专门的flush list 上，后续将由专门的刷脏线程阶段性的将这些页面写入磁盘。这样的好处是避免每次写操作都操作磁盘导致大量的随机 IO，阶段性的刷脏可以将多次对页面的修改 merge 成一次IO 操作，同时异步写入也降低了访问的时延。
然而，如果在 dirty page 还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb 将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是 redo log file。这样的技术推迟了 bp 页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写 redo log 操作的开销（顺序 IO，比随机 IO 快很多），以及数据库启动时恢复操作所需的时间。
其他
重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为8M,Innodb存储引擎先将重做日志写入innodb_log_buffer中。
然后会通过以下三种方式将innodb日志缓冲区的日志刷新到磁盘
-
Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件。
-
每个事务提交时会将重做日志刷新到重做日志文件。
-
当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件
由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，Innodb_log_buffer到重做日志文件是Master Thread线程的定时任务。
因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。
另外引用《MySQL技术内幕 Innodb 存储引擎》（page37）上的原话：
即使某个事务还没有提交，Innodb存储引擎仍然每秒会将重做日志缓存刷新到重做日志文件。
这一点是必须要知道的，因为这可以很好地解释再大的事务的提交（commit）的时间也是很短暂的。
undo-log 回滚日志
作用
保证数据的原子性
undo-log保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。
内容
逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo-log的。
什么时候产生
事务开始之前，将当前事务的版本生成undo-log，undo也会产生redo日志来保证undo-log的可靠性。
什么时候释放
当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。
对应的物理文件
| MySQL5.6之前 | MySQL5.6之后 |
|---|---|
| undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。 | undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo-log文件的个数如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。 |
关于MySQL5.7之后的独立undo 表空间配置参数如下：
| 配置项 | 配置内容 | 默认 |
|---|---|---|
| innodb_undo_directory | 独立表空间的存放目录。 | ./ |
| innodb_undo_logs | 回滚段大小 | 128 |
| innodb_undo_tablespaces | undo-log的文件数量量 | 0 |
如果undo使用的共享表空间，这个共享表空间中又不仅仅是存储了undo的信息，共享表空间的默认为与MySQL的数据目录下面，其属性由参数innodb_data_file_path配置。
其他
- 事务提交前需要将 Undo Log 写磁盘（提供可回滚功能，保证原子性），这会造成多次磁盘 IO（不考虑各种优化例如 SQL 解析优化等），这些 IO 算是顺序 IO；
- 事务提交后需要将数据立即更新到数据库中，这又会造成至少一次磁盘 IO，这是一次随机 IO。
undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。
默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中的。
因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。
因此，mysql5.7之后，独立undo表空间的配置就显得很有必要了。