MySQL中undo log、redo log、bin log相关知识

关注

原创 2024-04-13 21:09:37 2k 阅读 AI 写同款· GEO 优化 ›

从Maya到Unity：3D模型导入全流程避坑指南（含FBX导出设置）本文详细解析了从Maya导出3D模型至Unity的全流程，重点剖析了FBX格式作为跨软件协作“中间人”的优劣与核心设置。指南涵盖了Maya端模型清理、FBX导出关键配置（如嵌入媒体、轴转换），以及Unity端的模型、材质、动画导入优化与常见问题（如材质丢失、UV法线错误、骨骼动画错乱）的实战解决方案，旨在帮助3D美术师与技术美术建立稳定、高效的工作流。阅读详情

undo log

基本概念

undo log是一种用于撤销回退的日志，在数据库事务开始之前，MySQL会先记录更新前的数据到undo log日志文件里面，当事务回滚时或者数据库崩溃时，可以利用undo log来进行回退。
undo log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。

注意：undo log也会产生redo log，因为undo log也要实现持久性保护。

作用

提供回滚操作【undolog实现事务的原子性】

在数据修改的时候，不仅记录了redo log，还记录了相对应的undo log，如果因为某些原因导致事务执行失败了，可以借助undolog进行回滚。
undolog和redolog 记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undolog中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。

提供多版本控制【undolog实现多版本并发控制（MVCC）】

MVCC，即多版本控制。在MySQL数据库InnoDB存储引擎中，用undoLog来实现多版本并发控制(MVCC)。当读取的某一行被其他事务锁定时，它可以从undolog中分析出该行记录以前的数据版本是怎样的，从而让用户能够读取到当前事务操作之前的数据【快照读】。

redo log

基本概念

InnoDB引擎对数据的更新，是先将更新记录写入redolog日志，然后会在系统空闲的时候或者是按照设定的更新策略再将日志中的内容更新到磁盘之中。这就是所谓的预写式技术（Write Ahead logging）。这种技术可以大大减少IO操作的频率，提升数据刷新的效率。
redo log：被称作重做日志，包括两部分：一个是内存中的日志缓冲：redo log buffer，另一个是磁盘上的日志文件：redo Log file。

作用

Mysql每执行一条DML语句，先将记录写入redolog buffer。后续某个时间点再一次性将多个操作记录写到 redo log file。当故障发生致使内存数据丢失后，InnoDB会在重启时，经过重放 redo，将Page恢复到崩溃之前的状态通过Redo log可以实现事务的持久性。

binlog

基本概念

binlog是一个二进制格式的文件，用于记录用户对数据库更新的SQL语句信息，例如更改数据库表和更改内容的SQL语句都会记录到binlog里，但是不会记录SELECT和SHOW这类操作。
binlog在MySQL的Server层实现(引擎共用)
binlog为逻辑日志，记录的是一条SQL语句的原始逻辑
- binlog不限制大小,追加写入,不会覆盖以前的日志.
- 默认情况下，binlog日志是二进制格式的，不能使用查看文本工具的命令（比如，cat，vi等）查看，而使用mysglbinlog解析查看。

作用

主从复制：主库中开启Binlog功能，这样主库就可以把Binlog传递给从库，从库拿到Binlog后实现数据恢复达到主从数据一致性。
数据恢复：通过mysqlbinlog工具来恢复数据。

redo log和undo log的持久化策略

redo log持久化

缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统缓冲区(OS Buffer）。因此，redo log buffer写入redo log file实际上是先写入OSBuffer，然后再通过系统调用fsync()将其刷到redo log file.
Redo Buffer 持久化到 redo log 的策略，可通过 Innodb_flush_log_at_trx_commit 设置：

一般建议选择取值2，因为MySQL挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数据。

undo log持久化

MySQL中的UndoLog严格的讲不是Log，而是数据，因此他的管理和落盘都跟数据是一样的：

undo log的磁盘结构并不是顺序的，而是像数据一样按Page管理
undo写入时，也像数据一样产生对应的RedoLog（因为undo也是对页面的修改，记录undo这个操作本身也会有对应的redo)。
undo的Page也像数据一样缓存在Buffer Pool中，跟数据Page一起做LRU换入换出，以及刷脏。Undo Page的刷脏也像数据一样要等到对应的RedoLog落盘之后

当事务提交的时候，innodb不会立即删除undolog，因为后续还可能会用到undolog，如隔离级别为repeatableread时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。
但是在事务提交的时候，会将该事务对应的undolog放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undolog页而浪费存储空间和性能。

binlog和redo log的区别

redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。
redo log是物理日志，记录的是“在xxx数据页上做了xxx修改"；binlog是逻辑日志，记录的是原始逻辑，其记录是对应的SQL语句。(比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新；)
1. 物理日志：记录的是每一个page页中具体存储的值是多少，在这个数据页上做了什么修改．比如：某个事物将系统表空间中的第100个页面中偏移量为1000处的那个字节的值1改为2.
2. 逻辑日志：记录的是每一个page页面中具体数据是怎么变动的，它会记录一个变动的过程或SQL语句的逻辑，比如：把一个page页中的一数据从1改为2，再从2改为3,逻辑日志就会记录1->2,2->3这个数据变化的过程.
redo log是循环写的，空间一定会用完，需要writepos和checkpoint搭配；binlog是追加写，写到一定大小会切换到下一个，并不会覆盖以前的日志。

redo Log文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

write pos：表示日志当前记录的位置，当ib_logfile_4写满后，会从ib_logfile_1从头开始记录；
checkpoint：表示将日志记录的修改写进磁盘，完成数据落盘，数据落盘后checkpoint会将日志上的相关记录擦除掉，即 write pos->checkpoint 之间的部分是redo log空着的部分，用于记录新的记录，checkpoint->writepos之间是redolog待落盘的数据修改记录.
如果write pos追上checkpoint，表示写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint 推进一下。