undo log的相关操作执行delete操作时undo log会把记录中的内容记下来回滚的时候再insert回去而且在delete的时候不是立即删除而是打上delete flag标记由purge线程删除执行update操作时如果不是主键列在undo log中直接反向记录是如何update的。即update是直接进行的如果是主键列update分两部执行先删除该行再插入一行目标行。undo log的两大作用实现事务回滚保障事务原子性实现MVCC关键因素之一Buffer Pool的作用读取数据时会优先去Buffer Pool中寻找没有再去磁盘中读取修改数据会改Buffer Pool中的页将其设置为脏页后续由后台线程选择时机刷到磁盘Buffer Pool缓存什么数据页、索引页、插入缓存页、undo页、自适应哈希索引、锁信息…什么是 redo logredo log 是物理日志记录了某个数据页做了什么修改比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新每当执行一个事务就会产生这样的一条或者多条物理日志。为什么需要redo log将写操作由随机写变成顺序写保证了事务的持久性保持了崩溃恢复能力产生的 redo log 是先写入自己的缓存—— redo log bufferredo log 的刷盘时机MySQL关闭时当 redo log buffer 中记录的写入量大其内存空间的一半时InnoDB 的后台线程每隔 1 秒将 redo log buffer 持久化到磁盘在每次事务提交时innodb_flush_log_at_trx_commit 参数参数为0时事务的提交不会主动触发redo log写入磁盘的操作InnoDB 的后台线程每隔 1 秒通过调用 write() 写到操作系统的 Page Cache然后调用 fsync() 持久化到磁盘参数为1时每次事务的提交都会将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘参数为2时次事务的提交都会将缓存在 redo log buffer 里的 redo log 写到redo log文件中意味着写入到了操作系统的文件缓存InnoDB 的后台线程每隔 1 秒调用 fsync将缓存在操作系统中 Page Cache 里的 redo log 持久化到磁盘redo log 文件写满了怎么办InnoDB 存储引擎有 1 个重做日志文件组( redo log Group由两个 redo log 文件组成重做日志文件组是以循环写的方式工作的。其中有两个参数write pos表示当前记录写到的位置checkpoint表示当前要擦除的位置如果 write pos 追上了 checkpoint就意味着 redo log 文件满了这时 MySQL 不能再执行新的更新操作此时会停下来将 Buffer Pool 中的脏页刷新到磁盘中然后标记 redo log 哪些记录可以被擦除接着对旧的 redo log 记录进行擦除等擦除完旧记录腾出了空间checkpoint 就会往后移动binlog的作用binlog 文件是记录了所有数据库表结构变更和表数据修改的日志不会记录查询类的操作redo log 和 binlog 的区别适用对象不同一个是server层的日志所有引擎都适用一个是Innodb独有文件格式不同binlog 有 3 种格式类型分别是 STATEMENT默认格式、ROW、 MIXEDredo log 是物理日志写入方式不同一个是追加写一个是循环写用途不同binlog 用于备份恢复、主从复制redo log 用于掉电等故障恢复如果不小心整个数据库的数据被删除了只能使用binlog 文件恢复主从复制的实现写入 Binlog主库写 binlog 日志提交事务并更新本地存储数据。同步 Binlog把 binlog 复制到所有从库上每个从库把 binlog 写到暂存日志中。回放 Binlog回放 binlog并更新存储引擎中的数据。主从复制模型同步复制MySQL 主库提交事务的线程要等待所有从库的复制成功响应才返回客户端结果异步复制默认模型半同步复制事务线程不用等待所有的从库复制成功响应只要一部分复制成功响应回来就行binlog 什么时候刷盘事务执行过程中先把日志写到 binlog cacheServer 层的 cache事务提交的时候再把 binlog cache 写到 binlog 文件中执行一条update语句的流程执行器具体执行会检查buffer pool是否存在目标行记录执行器在得到聚簇索引记录会检查更新前后的记录是否一致来决定是否启用事务开启事务首先记录相应的undo log然后Buffer Pool中的Undo页面中Innodb层在更新记录会优先更新缓存修改完成之后记录对应的redo log后续由后台线程异步的将脏页和redo log写入磁盘在一条更新语句执行完成后开始记录该语句对应的 binlog此时记录的 binlog 会被保存到 binlog cache并没有刷新到硬盘上的 binlog 文件事务提交剩下的就是「两阶段提交」为什么需要两阶段提交MySQL 为了避免出现两份日志之间的逻辑不一致的问题使用了「两阶段提交」来解决,分别是「准备Prepare阶段」和「提交Commit阶段」如果在将 redo log 刷入到磁盘之后 MySQL 突然宕机了而 binlog 还没有来得及写入。如果在将 binlog 刷入到磁盘之后 MySQL 突然宕机了而 redo log 还没有来得及写入。两阶段提交流程prepare 阶段将 XID内部 XA 事务的 ID 写入到 redo log同时将 redo log 对应的事务状态设置为 prepare然后将 redo log 持久化到磁盘commit 阶段把 XID 写入到 binlog然后将 binlog 持久化到磁盘sync_binlog 1 的作用接着调用引擎的提交事务接口将 redo log 状态设置为 commit此时该状态并不需要持久化到磁盘只需要 write 到文件系统的 page cache 中就够了因为只要 binlog 写磁盘成功就算 redo log 的状态还是 prepare 也没有关系一样会被认为事务已经执行成功两阶段提交的问题磁盘 I/O 次数高每个事务提交都会进行两次 fsync刷盘锁竞争激烈在「多事务」的情况下却不能保证两者的提交顺序一致还需要加一个锁来保证提交的原子性