【数据库02】优化、视图、触发器、锁、InnoDB引擎、事务高级

个人学习笔记记录
参考资料：数据库从入门到精通

😀SQL优化

🎶insert

主键优化

主键顺序插入的性能是要高于乱序插入的

InnoDB的逻辑结构图

在这里插入图片描述

数据行是记录在page中的，而每一个页的大小是固定的，默认16K。那也就意味着，一个页中所存储的行也是有限的，如果插入的数据行row在该页存储不下，将会存储到下一个页中，页与页之间会通过指针连接。

页分裂

👉页可以为空，也可以填充一半，也可以填充100%
1. 当主键顺序插入时，会先填充1#，放不下了再写入2#，1#和2#通过指针连接。依此类推
2. 当主键乱序插入时，会产生页分裂现象：比如插入一个数据50，应该插入在49的后面，但此时49所在的页（比如说是1#）已满，就会开辟新页（比如说是3#，2#已有数据也满了），然后将1#的后半段移动到3#中，再把50插入3#的末尾，1#的指针改成与3#连接，2#的指针改向与3#连接，属于耗费性能的操作
页合并

👉当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用。

👉当页中删除的记录达到MERGE_THRESHOLD（默认为页的50%），InnoDB会开始寻找最靠近的页（前或后）看看是否可以将两个页合并以优化空间使用。

👉MERGE_THRESHOLD是合并页的阈值，可以自己设置，在创建表或者创建索引时指定。

满足业务需求的情况下，尽量降低主键的长度。

插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键

尽量不要使用UUID做主键或者是其他自然主键，如身份证号。

业务操作时，避免对主键的修改。

order by优化

两种优化方式：
- Using filesort : 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区 sort buffer 中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。
- Using index 👌: 通过有序索引顺序扫描直接返回有序数据，这种情况即为 using index，不需要额外排序，操作效率高。

根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则。

尽量使用覆盖索引。

多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）

如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)。

group by 优化

在分组操作时，可以通过索引来提高效率。

分组操作时，索引的使用也是满足最左前缀法则的。

limit 优化

超大分页通过 覆盖索引+子查询 形式进行优化。9

这里比较抽象，写个案例

#原sql：需要MYSQL排序前2000010条记录再返回200000-2000010的记录，其他记录丢弃
select * from tb limit 2000000, 10;

#优化sql
select * from tb t, (select id from tb order by id limited 2000000, 10) a where t.id = a.id;

count 优化

👉不同引擎下，count(*) 的不同执行过程

MyISAM ：把一个表的总行数存在了磁盘上，执行count(*) 的时候会直接返回这个数，效率很高；但是如果是带条件的count，MyISAM也慢。
**InnoDB **：执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。

按照效率排序，count(字段) < count(主键 id) < count(1) ≈ count(*)，所以尽量使用count(*)。

🎶update

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁升级为表锁。

比如：update course set name = 'javaEE' where id = 1 ;会锁定id为1这一行的数据，然后事务提交之后，行锁释放。但是开启多个事务，执行update course set name = 'SpringBoot' where name = 'PHP' ;会出现行锁升级成表锁的情况

😀视图

👉 视图（View）是一种虚拟存在的表。视图中的数据并不在数据库中实际存在，行和列数据来自定义视图的查询中使用的表（基表），并且是在使用视图时动态生成的。通俗的讲，视图只保存了查询的SQL逻辑，不保存查询结果。所以我们在创建视图的时候，主要的工作就落在创建这条SQL查询语句上。

创建/查看/修改视图

创建\修改视图

create or replace view viewname1 as select column1, column2 from table1 where id <= 10;
# 修改的另一种方式
alter view viewname1 as select column1, column2 from table1 where id <= 10;

查看

# 查看创建视图语句
show create view viewname1;
# 查看视图数据
select * from viewname1；

删除

drop view [if exists] viewname1

插入/更新/删除视图

检查选项

使用WITH CHECK OPTION子句创建视图时，MySQL会通过视图检查正在更改的每个行，例如插入，更新，删除，以使其符合视图的定义。

create or replace view viewname1 as select column1, column2 from table1 where id <= 10 with check option;

MySQL允许基于另一个视图创建视图，它还会检查依赖图中的规则以保持一致性。为了确定检查的范围，mysql提供了两个选项： CASCADED 和 LOCAL ，默认值为 CASCADED

create or replace view viewname1 as select column1, column2 from table1 where id <= 10 with cascade check option;

比如，v2视图是基于v1视图的

如果在v2视图创建的时候指定了检查选项为 cascaded，但是v1视图创建时未指定检查选项。则在执行检查时，不仅会检查v2，还会级联检查v2的关联视图v1
如果在v2视图创建的时候指定了检查选项为 local ，但是v1视图创建时未指定检查选项。则在执行检查时，知会检查v2，不会检查v2的关联视图v1

更新

如果视图包含以下任何一项，则该视图不可更新：

聚合函数或窗口函数
DISTINCT
GROUP BY
HAVING
UNION或者UNION ALL

视图的作用

简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件
数据库可以授权，但不能授权到数据库特定行和特定的列上。通过视图用户只能查询和修改他们所能见到的数据
视图可帮助用户屏蔽真实表结构变化带来的影响

😀触发器

👉在insert/update/delete之前(BEFORE)或之后(AFTER)，触发并执行触发器中定义的SQL语句集合。

👉在数据库端确保数据的完整性 , 日志记录 , 数据校验等操作

触发器类型	NEW和OLD
INSERT	NEW表示将要或者已经新增的数据
UPDATE	OLD表示修改之前的数据，NEW表示将要或已经修改后的数据
DELETE	OLD表示将要或已经删除的数据

创建/查看/修改触发器

CREATE TRIGGER trigger_name
BEFORE/AFTER INSERT/UPDATE/DELETE
ON tbl_name FOR EACH ROW -- 行级触发器
BEGIN
trigger_stmt ; -- 这里写触发器里面的语句
END;

show triggers;

drop trigger [scheme_name.] trigger_name; -- 不指定scheme_name则默认为当前数据库

案例

-- 创建用户表
create table tb_user(
id int primary key auto_increment comment '主键',
name varchar(50) not null comment '用户名',
phone varchar(11) not null comment '手机号',
email varchar(100) comment '邮箱',
profession varchar(11) comment '专业',
age tinyint unsigned comment '年龄',
gender char(1) comment '性别 , 1: 男, 2: 女',
status char(1) comment '状态',
createtime datetime comment '创建时间'
) comment '系统用户表';

-- 插入用户数据
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('吕布', '17799990000', 'lvbu666@163.com', '软件工程', 23, '1',
                                         '6', '2001-02-02 00:00:00');
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('曹操', '17799990001', 'caocao666@qq.com', '通讯工程', 33,
                                         '1', '0', '2001-03-05 00:00:00');
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('赵云', '17799990002', '17799990@139.com', '英语', 34, '1',
                                         '2', '2002-03-02 00:00:00');
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('孙悟空', '17799990003', '17799990@sina.com', '工程造价', 54,
                                         '1', '0', '2001-07-02 00:00:00');
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('花木兰', '17799990004', '19980729@sina.com', '软件工程', 23,
                                         '2', '1', '2001-04-22 00:00:00');
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('大乔', '17799990005', 'daqiao666@sina.com', '舞蹈', 22, '2',
                                         '0', '2001-02-07 00:00:00');
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,
                     createtime) VALUES ('露娜', '17799990006', 'luna_love@sina.com', '应用数学', 24,
                                         '2', '0', '2001-02-08 00:00:00');
-- 创建日志表
create table user_logs(
                          id int(11) not null auto_increment,
                          operation varchar(20) not null comment '操作类型, insert/update/delete',
                          operate_time datetime not null comment '操作时间',
                          operate_id int(11) not null comment '操作的ID',
                          operate_params varchar(500) comment '操作参数',
                          primary key(`id`)
)engine=innodb default charset=utf8;

-- 创建插入触发器
create trigger tb_user_insert_trigger
    after insert on tb_user for each row
begin
    insert into user_logs(id, operation, operate_time, operate_id, operate_params)
    VALUES
        (null, 'insert', now(), new.id, concat('插入的数据内容为:
id=',new.id,',name=',new.name, ', phone=', NEW.phone, ', email=', NEW.email, ',
profession=', NEW.profession));
end;

-- 展示下触发器
show triggers;

-- 测试下触发器，测试完看日志中有无数据且用户表中是否发生变化
insert into tb_user(id, name, phone, email, profession, age, gender, status,
                    createtime) VALUES (26,'三皇子','18809091212','erhuangzi@163.com','软件工
程',23,'1','1',now());

-- 创建更新触发器
create trigger tb_user_update_trigger
    after update on tb_user for each row
begin
    insert into user_logs(id, operation, operate_time, operate_id, operate_params)
    VALUES
        (null, 'update', now(), new.id,
         concat('更新之前的数据: id=',old.id,',name=',old.name, ', phone=',
                old.phone, ', email=', old.email, ', profession=', old.profession,
                ' | 更新之后的数据: id=',new.id,',name=',new.name, ', phone=',
                NEW.phone, ', email=', NEW.email, ', profession=', NEW.profession));
end;

update tb_user set profession = '舞蹈' where id = 26;

-- 创建删除触发器
create trigger tb_user_delete_trigger
    after delete on tb_user for each row
begin
    insert into user_logs(id, operation, operate_time, operate_id, operate_params)
    VALUES
        (null, 'delete', now(), old.id,
         concat('删除之前的数据: id=',old.id,',name=',old.name, ', phone=',
                old.phone, ', email=', old.email, ', profession=', old.profession));
end;

delete from tb_user where id = 26;

😀锁

🎵解决并发访问出现的数据访问一致性、有效性问题

全局锁

🎵锁住数据库中的所有表

👉应用场景：全库的逻辑备份（对所有表进行锁定从而获取一致性视图，保证数据完整性）

加全局锁

flush tables with read lock;

数据备份

mysqldump -uroot -p1234 yjy > yjy.sql

释放锁

unlock tables;

缺点：利用全局锁，如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆。如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导致主从延迟。

解决方案：不加锁的一致性数据备份
mysqldump --single-transaction -uroot -p1234 lim > lim.sql

表级锁

🎵锁住整张表

表锁

🎵分为表共享读锁 read lock和表独占写锁 write lock，读锁不会阻塞其他客户端的读，但是会阻塞写。写锁既会阻塞其他客户端的读，又会阻塞其他客户端的写。

加锁

lock tables 表名... read/write

释放锁

unlock tables

元数据锁

🎵meta data lock，简称MDL，是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。

👉元数据：简单理解为就是一张表的表结构。也就是说，某一张表涉及到未提交的事务时，是不能够修改这张表的表结构的

👉当对一张表进行增删改查的时候，加元数据共享锁（SHARED_READ/ SHARED_WRITE），会阻塞元数据排它锁；当对表结构进行变更操作的时候，加元数据排它锁（EXCLUSIVE）。

主要作用：
- 维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。
- 避免DML与DDL冲突，保证读写的正确性。
常见SQL操作对应添加的元数据锁
- lock tables xxx 表名... read/write加表锁：SHARED_READ_ONLY / SHARED_NO_READ_WRITE
- select 、select ... lock in share mode：SHARED_READ
- insert 、update、 delete、select ... for update：SHARED_WRITE
- alter table ...：EXCLUSIVE
查看加锁情况

select object_type,object_schema,object_name,lock_type,lock_duration from
performance_schema.metadata_locks ;

意向锁

🎵DML在执行时，加的表锁可能与行锁有冲突，使用意向锁就能够让使得表锁不用检查每行数据是否加锁，减少了表锁的检查。

👉做法：在执行DML操作时，会对涉及的行加行锁，同时也会对该表加上意向锁。而其他客户端，在对这张表加表锁的时候，会根据该表上所加的意向锁来判定是否可以成功加表锁，而不用逐行判断行锁情况了。一旦事务提交了，意向共享锁、意向排他锁，都会自动释放。

👉分类：

意向共享锁(IS): 由语句select ... lock in share mode添加。与表锁共享锁 (read)兼容，与表锁排他锁(write)互斥。

意向排他锁(IX): 由insert、update、delete、select...for update添加。与表锁共享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥。

查看加锁情况

select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from
performance_schema.data_locks;

行级锁

🎵锁住对应的行数据，InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。

行锁（Record Lock）

🎵锁定单个行记录的锁，防止其他事务对此行进行update和delete。在 RC、RR隔离级别下都支持。

👉分类：

共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁。

排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。

👉InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁。

SQL	行锁	说明
增删改	排他锁	自动加锁
普通查（select）	不加任何锁	-
牛逼查（select … lock in share mode）	共享锁	手动加 lock in share mode
牛逼查（select … for update）	排他锁	手动加 for update

间隙锁（Gap Lock）

🎵锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。

👉间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。

临键锁（Next-Key Lock）

🎵行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap，在RR隔离级别下支持。

索引上的等值查询(唯一索引)，给不存在的记录加锁时，优化为间隙锁。
索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-key lock 退化为间隙锁。
索引上的范围查询(唯一索引)-- 会访问到不满足条件的第一个值为止。

😀InnoDB引擎

逻辑存储结构

在这里插入图片描述

表空间

👉是InnoDB存储引擎逻辑结构的最高层，如果用户启用了参数 innodb_file_per_table(在 8.0版本中默认开启) ，则每张表都会有一个表空间（xxx.ibd）

👉一个mysql实例可以对应多个表空间，用于存储记录、索引等数据。

👉分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段（Rollback segment）

👉InnoDB是索引组织表，数据段就是B+树的叶子节点，索引段即为B+树的非叶子节点。

👉表空间的单元结构，每个区的大小为1M

👉默认情况下， InnoDB存储引擎页大小为16K，即一个区中一共有64个连续的页。

👉是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。

👉为了保证页的连续性， InnoDB 存储引擎每次从磁盘申请 4-5 个区。

👉InnoDB存储引擎数据是按行进行存放的。

👉两个默认隐藏字段：Trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。Roll_pointer：每次对某条引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

架构

内存结构

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

Buffer Pool 缓冲池

是什么：是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池没有数据，则从磁盘加载并缓存），然后再以一定频率刷新到磁盘，从而减少磁盘IO，加快处理速度。

有什么：缓存了索引页和数据页，undo页、插入缓存、自适应哈希索引以及 InnoDB的锁信息等等。

why？InnoDB存储引擎是基于磁盘文件存储，访问物理硬盘和访问内存的速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行磁盘I/O。

底层原理
- 缓冲池以Page页为单位，底层采用链表数据结构管理Page。
- 根据状态，将Page分为三种类型：
  
  👉free page：空闲page，未被使用。
  
  👉clean page：被使用page，数据没有被修改过。
  
  👉dirty page：脏页，被使用page，数据被修改过，也中数据与磁盘的数据产生了不一致。
在专用服务器上，通常将多达**80％**的物理内存分配给缓冲池。参数设置： show variables like 'innodb_buffer_pool_size';

Change Buffer 更改缓冲区

是什么：针对非唯一二级索引页的，在执行DML时，如果数据页不在缓冲池中，就将这些DML语句保存在Change Buffer中，等到未来读取数据页时（这时把磁盘中的数据页读取到了缓冲池），再把Change Buffer中的DML变更到缓冲池中，然后再将修改写回磁盘。

why：与聚集索引不同，二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引。同样，删除和更新可能会影响索引树中不相邻的二级索引页，如果每一次都操作磁盘，会造成大量的磁盘IO。有了 Change Buffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO。

Adaptive Hash Index

是什么：用于优化对Buffer Pool数据的查询。

why：MySQL的InnoDB引擎中没有直接支持 hash索引，通过自适应Hash Index可以实现。hash索引在进行等值匹配时，一般性能是要高于B+树的，因为hash索引一般只需要一次IO即可，而B+树，可能需要几次匹配，所以hash索引的效率要高，但是hash索引又不适合做范围查询、模糊匹配等。

底层原理
- InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在特定的条件下hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。
- 自适应哈希索引，无需人工干预，是系统根据情况自动完成。
- 参数： adaptive_hash_index

Log Buffer

是什么：日志缓冲区，里面的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘 I/O。

有什么：要写入到磁盘中的log日志数据（redo log 、undo log），默认大小为 16MB

底层
- innodb_log_buffer_size：缓冲区大小
- innodb_flush_log_at_trx_commit：日志刷新到磁盘时机。1: 日志在每次事务提交时写入并刷新到磁盘，默认值。 0: 每秒将日志写入并刷新到磁盘一次。 2: 日志在每次事务提交后写入，并每秒刷新到磁盘一次。

磁盘结构

在这里插入图片描述

System Tablespace 系统表空间

👉是更改缓冲区的存储区域。

👉如果表是在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)

👉innodb_data_file_path：默认的文件名叫ibdata1

File-Per-Table Tablespaces 文件表空间

👉如果开启了innodb_file_per_table开关（默认开启），则每个表的文件表空间包含单个InnoDB表的数据和索引，并存储在文件系统上的单个数据文件中.ibd。

👉每创建一个表都会产生一个表空间

General Tablespaces 通用表空间

👉创建通用表空间

create tablespace ts_name add datafile 'file_name' engine = e_name;

👉在创建表时，可以指定该表空间。

create table (建表语句) tablespace ts_name

Undo Tablespaces 撤销表空间

👉用于存储 undo log日志。

👉MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M）

Temporary Tablespaces 临时表空间

👉分为会话临时表空间和全局临时表空间

👉存储用户创建的临时表等数据

Doublewrite Buffer Files 双写缓冲区

👉将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据。

Redo Log 重做日志

👉是用来实现事务的持久性。

👉由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）, 前者是在内存中，后者在磁盘中

👉当事务提交之后会把所有修改信息都会存到该日志中，用于在刷新脏页到磁盘时，发生错误进行数据恢复使用。

后台线程

🎵把内存中所更新的数据同步到磁盘中

Master Thread 核心后台线程

👉负责调度其他线程

👉负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性

👉包括脏页的刷新、合并插入缓存、undo页的回收。

IO Thread

👉InnoDB大量使用了AIO来处理IO请求, 这样可以极大地提高数据库的性能，IO Thread主要负责这些IO请求的回调。

👉四个AIO：Read threadX4、Write threadX4、Log threadX1、Insert Buffer threadX1

👉如何看IO Thread信息：show engine innodb status \G

Purge Thread

用于回收事务已经提交了的undo log，在事务提交之后，undo log可能不用了，就用它来回收。

Page Cleaner Thread

协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻 Master Thread 的工作压力，减少阻塞。

😀事务

在这里插入图片描述

redo log

🎵记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。redo log buffer-在内存中；redo log file-在磁盘中

👉Background：在InnoDB引擎中的内存结构中，主要的内存区域就是缓冲池，在缓冲池中缓存了很多的数据页。当我们在一个事务中，执行多个增删改的操作时，InnoDB引擎会先操作缓冲池中的数据，如果缓冲区没有对应的数据，会通过后台线程将磁盘中的数据加载出来，存放在缓冲区中，然后将缓冲池中的数据修改，修改后的数据页我们称为脏页。而脏页则会在一定的时机，通过后台线程刷新到磁盘中，从而保证缓冲区与磁盘的数据一致。而缓冲区的脏页数据并不是实时刷新的，而是一段时间之后将缓冲区的数据刷新到磁盘中，假如刷新到磁盘的过程出错了，而提示给用户事务提交成功，而数据却没有持久化下来，这就出现问题了，没有保证事务的持久性。

👉底层原理：当对缓冲区的数据进行增删改之后，会首先将操作的数据页的变化，记录在redo log buffer中。在事务提交时，会将redo log buffer中的数据刷新到redo log file中。过一段时间之后，如果刷新缓冲区的脏页到磁盘时，发生错误，此时就可以借助于redo log进行数据恢复，这样就保证了事务的持久性。而如果脏页成功刷新到磁盘或者涉及到的数据已经落盘，此时redo log就没有作用了，就可以删除了，所以存在的两个redo log文件是循环写的

❓为什么明明都是同步，但是redo log的同步要比缓冲池与数据页同步的性能好呢？（为什么每一次提交事务，要刷新redo log 到磁盘中呢，而不是直接将buffer pool中的脏页刷新到磁盘呢）
🤖因为redo log的同步是一个顺序磁盘IO，而缓冲池和数据页同步是随机磁盘IO。顺序写的效率，要远大于随机写。这种先写日志的方式，称之为 WAL（Write-Ahead Logging）。

undo log

🎵回滚日志，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和 MVCC(多版本并发控制) 。

👉undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC。具体来说：当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。
undo log存储：undo log采用段的方式进行管理和记录，存放在rollback segment 回滚段中，内部包含1024个undo log segment。
redolog + undolog保证了事务的一致性

MVCC

🎵全称Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

👉MVCC + 锁，实现了事务的隔离性。