数据查询网站模板,用小程序做网站,个人工作总结ppt模板免费,wordpress 做博客MySQL 主要是通过: 锁、Redo Log、Undo Log、MVCC来实现事务 事务的隔离性利用锁机制实现 原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。 Redo Log(重做日志)#xff1a;记录事务对数据库的所有修改#xff0c;在崩溃时恢复未提交的更改#xff0c;保证事务…MySQL 主要是通过: 锁、Redo Log、Undo Log、MVCC来实现事务 事务的隔离性利用锁机制实现 原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。 Redo Log(重做日志)记录事务对数据库的所有修改在崩溃时恢复未提交的更改保证事务的持久性 Undo Log(回滚日志)保存数据的历史版本用于事务的回滚。用来保证事务的原子性、一致性 MVCC(多版本并发控制)满足了非锁定读的需求提高了并发度实现了读已提交可重复读级别的 事务隔离性。
redo日志
作用
在内存中修改完数据后更新数据记录到redo的磁盘日志中最后在同步数据回磁盘确保宕机时能恢复保证事务的持久性 redo日志占用的空间很小且降低了刷盘频率 redo日志是顺序写入磁盘的效率高 事务执行过程中redo log不断记录
redo log 是存引擎层产生的而binlog是数据库层产生的假设一个事务对表做了10万次记录插入在这个过程中会一直往redo log中顺序记录而binlog不会记录直到这个事务提交才会一次性写到bin log中
组成
Redo log可以简单分为以下两个部分redo_log_buffer、redo_log_file 重做日志的缓冲 (redo_log_buffer)保存在内存中是易失的 重做日志文件 (redo_log_file)保存在硬盘中是持久的。
在服务器启动时就向操作系统申请了一大片称之为redo log bufer的连续内存空间即redo日志缓冲区。被划分成若干个连续的redo log block。一个redo log block占用512字节大小。 参数设置innodb_log_buffer_size
redo log buffer 大小默认 16M最大值是4096M最小值为1M
mysql show variables like %innodb_log_buffer_size%;
----------------------------------
| Variable_name | Value |
----------------------------------
| innodb_log_buffer_size | 16777216 |
----------------------------------
流程
以一个更新事务为例redo log 流转过程如下图所示 redolog刷盘策略⭐
首先redo log会实时同步到redo_log_buffer之后以 一定的频率 刷入到真正的redo_log_file 中。
这里的一定频率怎么看待呢这就是我们要说的刷盘策略 注意redo_log_buffer刷盘到redo_log_file的过程并不是真正的刷到磁盘中去只是刷入到 文件系统缓存page_cache中去真正的写入会交给系统自己来决定比如page cache足够大了 所以对于InnoDB如果交给系统来同步如果系统宕机那么数据也丢失了
针对这种情况InnoDB给出 innodb_flush_log_at_trx_commit参数该参数控制提交事务时刷盘到redo_log_file中的三种策略 设置为0 表示每次事务提交时不进行刷盘操作。通过系统默认master thread每隔1s进行一次重做日志的同步 设置为1 表示每次事务提交时都将进行同步刷盘操作 默认值 设置为2 每次事务提交时都只把redo_log_buffer内容写入page_cache(文件系统的缓存)不进行同步。由os自己决定什么时候同步到磁盘文件
SET GLOBAL innodb_flush_log_at_trx_commit 1; 此外InnoDB 存储引擎有一个后台线程每隔1 秒就会把redo_log_buffer中的内容写到文件系统缓存(page cache)然后调用刷盘操作 其次当redo_log_buffer占用空间到 innnodb_buffer_size(默认16M)的一半时也会主动刷盘 当参数设置为1时只要事务提交成功就一定会存在redo.file中 若事务执行期间mysql挂了但redo.file通过后台线程自动刷盘保存了部分开始事务后的一些操作重启后InnoDB 利用undo回滚日志决定是否回滚 或者继续执行事务
undo日志
undo log是事务原子性的保证。在事务中更新数据的 前置操作 其实是要先写入一个 undo log 记录事务每一次修改的反向操作便于回滚
作用
因为原子性 即事务的操作要么全部完成要么什么也不做。假如执行到一半出现错误就可以利用undo log 回滚数据 作用1回滚数据
只是将数据库逻辑层面上恢复到原来的样子只能弥补如一些物理上的结构修改无法回滚到之前的状态比如undo日志中是逻辑删除 作用2MVCC多版本并发控制
MVCC的实现是通过undo log来完成的。当用户读取一行记录时若该记录已经被其他事务占用当前事务可以通过undo读取之前的行版本信息以此实现非锁定读取
组成
①回滚段与undo页
InnoDB对undo log的管理采用段的方式也就是 回滚段rollback segment 。每个回滚段记录了1024 个 undo log segment而在每个undo log segment段中进行 undo页 的申请。
undo页被设计为可以重用即当事务提交后并不会立即删除undo页会放到链表中判断其空间是否小于3/4小于则可以重用但是因为重用所以undo页中可能混杂其他事务的undo log重用的事务记录在其之后
②回滚段与事务 ③回滚段中的数据分类 生命周期 详细生成过程 当执行INSERT时
begin;
INSERT INTO user (name) VALUES (tom); 当执行UPDATE时
begin;
UPDATE user (name) to (Sun); UPDATE user SET id2 WHERE id1; #删除id1的数据并把id2的数据覆盖 undo log是如何回滚的 undo no 0记录的是 插入tom前的状态即不存在 undo no 1记录的数据是tom undo no 2记录的数据是Sun undo no 3记录的是id1 时的数据
那么假设要回滚
通过3的日志把id2的数据删除通过2的日志把id1的数据的deletemark还原成0
通过undo no1的日志把还原成Tom通过undo no0的日志把id1的数据删除 小结 先找是否有加载对应的BufferPool有就使用没有就加载读取 ---- 写入UndoLog —操作执行数据 — 写入RedoLogBuffer内存 ---- 写入RedoLog到磁盘文件
