1. Innodb逻辑存储结构
- 表空间：ibd文件
- 段segment：
- 区extent：一个区大小为1m，里面有64个page页；为了保证页的连续性innodb会一次从磁盘申请4-5个区
- 页page：一个page页大小为默认为16k
- 行row：Trx id、Roll_pointer、row_id（没有主键才有）、col1、col2、col3……
2. Innodb引擎架构
MySQL5.5版本开始默认使用Innodb引擎，因为它擅长事务处理，具有崩溃恢复特性，在日常开发中使用更加广泛
下图为Innodb引擎架构图，左侧为内存结构，右侧为磁盘结构
1. 内存
1. Buffer Pool
Buffer Pool缓冲池是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，从而减少磁盘的IO，加快处理速度
在执行增删改查的时候，先操作缓冲池Buffer Poll中的数据，缓冲池中找不到再去磁盘中加载并缓存，然后再以一定的频率将数据从内存中刷新到磁盘
Buffer Pool缓冲池中占用内存以Page页为单位，底层采用链表数据结构来管理Page页，根据状态将Page分为三种类型：
- free page：空闲的page，还没有被使用
- clean page：被使用过的page，数据没有被修改过
- dirty page：脏页，数据被使用且修改过，与磁盘中的不一致
2. Change Buffer
Changer Buffer更改缓冲区（针对非唯一二级索引页），在执行DML语句时，如果这些数据没有在Buffer Pool中，那么不会直接操作磁盘，而是先将数据写入Change Buffer，在未来数据被读取时合并到Buffer Pool中，再在Buffer Pool刷新到磁盘时写入
Change Buffer存在的意义
- 与聚集索引不同，二级索引通常是非唯一的且插入的顺序相对随机
- 同样，插入和更新的操作也容易影响索引书中不相邻的二级索引页导致页的分裂和合并造成大量磁盘IO
- 如果使用Change Buffer可以将数据刷新到Buffer Pool中统一刷新到磁盘
3. Log Buffer
Log Buffer日志缓冲区：用来保存需要写入到磁盘中的日志文件（redo log、undo log），默认大小为16MB，日志缓冲区中的文件会定时刷新到磁盘中。
存在的作用主要是：如果需要更新、插入、删除很多行的事务，使用日志缓冲区可以减少磁盘的IO
参数：
- innodb_log_buffer_size：缓冲区大小
- innodb_flush_log_at_trx_commit：日志刷新到磁盘时机；0每秒将日志写入并刷新到磁盘，1每次在事务提交时写入并将数据刷新到磁盘，2每次在事务提交时写入，每秒刷新到磁盘一次
4. Adaptive Hash Index
Adaptive Hash Index自适应哈希索引，用于优化对Buffer Pool中数据的查询；Innodb引擎会监控对表上各索引页的查询，如果观察到使用Hash索引可以提升速度，则自动建立Hash索引，称之为自适应索引
无需人工干预，系统自动完成
参数：innodb_adaptive_hash_index
2. 磁盘
1. System Tablespace
System Tablespace：系统表空间是Change Buffer更改缓冲区的存储区域；如果表不是在每个表文件或者通用表空间中创建的，System Tablespace也包含表和索引数据。在Mysql5.X版本中还包含InnoDB数据字典、undoLog等
主要包含：
- Change Buffer缓冲区的存储区域
- 不在表空间表空间和通用表空间创建的表
- 5.X版本还包含InnoDB数据字典和undolog等
参数：innodb_data_file_path；默认大小为12MB，自动扩展大小
2. File-per-table Tablespace
File-Per-Table Tablespace表文件表空间：Innodb中每张表都会有一个都会有一个自己单独的文件，存储数据和索引，这些文件放在表文件表空间中；通过参数可以控制是否存单独放在表文件表空间中
参数：innodb_file_per_table；默认为true，开启；如果关闭了，且创建表时没有指定通用表空间，则存放在系统表空间中
3. General Tablespace
General Tablespace通用表空间：可以在建表时通过语法，指定表存放在某个通用表空间中；如果没有开启innodb_file_per_table这个参数也没有指定通用表空间，那么表将会存放在系统表空间
# 创建表空间并指定表空间文件名和引擎类型
creat tablespace 表空间名 add datafile '文件名' engine = innodb|myisam|memory;
# 建表时指定通用表空间
create table 表名 tablespace 表空间名;
4. Undo Tablespace
Undo Tablespace撤销表空间：Mysql实例会在初始化时自动创建两个默认的undo表空间undo_001和undo_002，初始大小16M，用于存储undo log日志，实现MVCC
5. Temporary Tablespace
Temporary Tablespace：InnoDB使用会话临时表空间和全局临时表空间，来存储用户创建的临时表等数据
6. Doublewrite Buffer Files
Doublewrite Buffer Files双写缓冲区：innoDB引擎将数据页从Buffer Pool刷新到磁盘上前，先将数据页写入双写缓冲区文件中，便于异常时恢复数据
7. Redo Log
Redo Log重做日志：用来实现事务的持久性。该日志文件由两部分组成，日志缓冲区Redo Log Buffer和重做日志文件Redo Log组成，前者在内存中，后者在磁盘中。当事务提交后把所有修改信息存入该重做日志。当刷新脏页到磁盘中发生错误时，进行数据恢复使用
写入Redo Log日志文件时是循环写入的，涉及两个文件：ib_logfile0和ib_logfile1
3. 后台线程
在Innodb引擎中，还有一些后台线程负责处理数据
1. Master Thread
Master Thread主线程，核心后台线程,负责调度其他线程，同时还负责：
- 将数据从缓冲池Buffer Pool中异步刷新到磁盘上，保持数据的一致性
- 脏页的刷新、合并
- undo页的回收
2. IO Thread
在Innodb中大量使用了AIO来处理IO请求，这样可以提高数据库的性能，IO Thread主要负责这些IO请求的回调
| 线程类型 | 默认个数 | 职责 |
|---|---|---|
| Read Thread | 4 | 负责读操作 |
| Write Thread | 4 | 负责写操作 |
| Log Thread | 1 | 负责将日志缓冲区刷新到磁盘 |
| Insert Buffer Thread | 1 | 负责将写缓冲区内容刷新到磁盘 |
3. Purge Thread
主要用于回收事务已经提交的undo log；在事务提交之后，undo log可能不用了，就用它来回收不需要的undo log
4. Page Clean Thread
协助Master Thread刷新脏页到磁盘的线程，他可以减轻Master Thread的压力，减小阻塞
3. 事务原理
事务四大特性：原子性、隔离性、一致性、持久性
这四个特性可以分为两类：
- 原子性、一致性、持久性：通过redo log、undo log实现
- 隔离性：通过锁和MVCC实现
原子性-undo log、持久性-redo log、一致性-undo log+redo log、隔离性-锁+MVCC
1. redo log
redo log重做日志：记录的是数据提交时物理页的修改，用来实现事务的持久性
该日志文件由两部分实现，redo log buffer和redo log file，前者在内存中，后者在磁盘中；当事务提交之后会把所有修改信息都存到该日志文件中，当刷新脏页到磁盘中发生错误时，进行数据恢复使用
redo log file有两个：ib_logfile0和ib_logfile1，循环写入
2. undo log
undo log回滚日志：用于回滚和MVCC
redo log记录的物理数据的修改，而undo log是逻辑日志；可以当作在delete一条记录时，undo log会insert一条记录，在update一条记录时，同样会在undo log中update一个相反的数据；当执行rollback时，执行undo log中的记录就可以进行事物的回滚
undo log的销毁：undo log在事务开始时会立即产生；在事务提交后并不会立即删除，因为undo log还有可能会用于MVCC
undo log的存储：undo log采用段的方式进行管理，数据记录在回滚段Rollback Segment中，内部包含1024个undo log segment
4. MVCC
MVCC，全称Multi-Version Concurrency Control多版本并发控制，指的是维护一个数据的多个版本，用来实现事务的隔离性，快照读就是MVCC的表现形式
在查询数据的时候有两种方式：当前读和快照读，其中快照读未Mysql默认实现，无需显示控制，而当前读需要手动操作
MVCC的实现基于3个方面：3个隐藏字段、undo log、read view
1. 当前读和快照读
当前读
读取的是数据的最新版本
读取时还要保证其他并发事务不能修改当前记录，会对读取的记录加锁
select…in share mode（共享锁）、select…for update、update、delete、insert（排他锁）都是快照读
快照读
简单的select使用的就是快照读，读取的是当前数据的可见版本，有可能是历史数据，没有锁
在不同的隔离级别下，生成快照读的时机不同：
在Read Commited隔离级别下，每次select都会生成一个快照读；
在Repeatable Read隔离级别下，开启事务后的第一个select会生成一个快照读
在Serializable隔离级别下，快照读会退化为当前读（阻塞的）
2. MVCC实现原理
1. 3个隐藏字段
在每一行记录中，都有隐藏字段：DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID（未指定主键时才会有）
| 隐藏字段 | 含义 |
|---|---|
| DB_TRX_ID | 最近修改事务id，记录最后一次插入或者修改该记录的事务的id |
| DB_ROLL_PTR | 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本 |
| DB_ROW_ID | 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段 |
2. undo log和undo log版本链
undo log
undo log回滚日志，在增删改时产生的便于数据回滚的日志
- 当insert的时候，产生的undo log日志只在数据回滚时，事务提交后可以立即被删除；
- 当update、delete的时候产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会被立即删除
undo log版本链
不同事务或者相同事务对同一条记录进行更改，会导致该记录的undo log生成一条版本单向链表，链表的头部是最新的旧纪录，链表的尾部是最早的旧纪录
3. read view
ReadView读视图是快照读创建快照后，MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）的id；ReadView中包含4个核心字段：
| 字段 | 含义 |
|---|---|
| m_ids | 当前活跃的事务ID集合 |
| min_trx_id | 最小活跃事务ID |
| max_trx_id | 预分配事务ID，当前最大事务ID+1（因为事务ID是自增的） |
| creator_trx_id | ReadView创建者的事务ID |
在不同隔离级别下，生成ReadView读视图的时机不同：
- 在读已提交隔离级别下，每次select产生一个快照；会导致不可重复读的问题
- 在可重复读隔离级别下，当事务中的第一个select语句执行时会创建快照，后续复用该快照；会导致幻读
读视图是通过访问undo log版本链来实现，undo log中有很多条记录，读视图能够访问哪写记录由以下四个规则决定：
- trx_id == creator_trx_id? 可以访问该版本，因为数据是这个事务修改的
- trx_id < min_trx_id?可以访问该版本，因为数据已经提交了
- trx_id > max_trx_id?不可以访问该版本，因为该记录是在当前事务开启之后修改的
- min_trx_id <= trx_id <= max_trx_id? 如果trx_id不在m_ids中是可以访问的，说明数据已经提交
下面是示例
5. InnoDB总结
逻辑存储架构
表空间、段（数据段、回滚段、索引段）、区（1M）、页（16K）、行
架构
内存结构：Buffer Pool、Change Buffer、Log Buffer、Adaptive Hash Index
磁盘结构：系统表空间、文件表空间、通用表空间、撤销表空间、重做表空间、临时表空间、双写缓冲区
事务原理
原子性：undo log
一致性：undo log + redo log
持久性：redo log
隔离性：MVCC + 锁
MVCC
记录中隐藏字段：db_trx_id、db_roll_ptr、db_row_id
undolog+undolog版本链：
readview：4个访问规则，决定可以访问哪个版本的undo log
Hash Index
磁盘结构：系统表空间、文件表空间、通用表空间、撤销表空间、重做表空间、临时表空间、双写缓冲区
事务原理
原子性：undo log
一致性：undo log + redo log
持久性：redo log
隔离性：MVCC + 锁
MVCC
记录中隐藏字段：db_trx_id、db_roll_ptr、db_row_id
undolog+undolog版本链：
readview：4个访问规则，决定可以访问哪个版本的undo log
1278
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
