13 SQL进阶-InnoDB引擎（8.23）
一、逻辑存储结构
（1）表空间（ibd文件）：一个mysql实例可以对应多个表空间，用于存储记录、索引等数据。
cd /var/lib/mysql
（2）段，分为数据段（leaf node segment）、索引段（non-leaf node segment）、回滚段（rollback segment），InnoDB是索引组织表，数据段就是B+树的非叶子节点。段用来管理多个extent（区）。
（3）区，表空间的单元结构，每个区的大小为1M，默认情况下，InnoDB存储引擎页大小为16K，即一个区中一共有64个连续的页。
（4）页，是InnoDB存储引擎磁盘管理的最小单元，每个页的大小默认为16KB。为了保证页的连续性，InnoDB存储引擎每次从磁盘申请4-5个区。
（5）行，InnoDB存储引擎数据是按行进行存放的。
二、架构
1、架构图
MySQL5.5版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，在日常开发中使用非常广泛。
InnoDB架构图，左侧内存结构，右侧磁盘结构。
2、内存结构
（1）buffer pool：缓冲池
dirty page：缓冲区的页还没有刷新到磁盘上。
（2）change buffer：更改缓冲区
对唯一索引和主键索引不会操作更改缓冲区。
在执行增删改语句时，不是直接操作到磁盘，而是将数据变更存放在更改缓冲区，再以一定频率将将数据放入缓冲池，再刷新到磁盘中。
（3）log buffer：日志缓冲区
（4）adaptive hash index：自适应哈希索引
InnoDB默认不支持哈希索引，默认B+索引。哈希索引不支持范围查询，支持等值匹配。
3、磁盘结构
（1）system tablespace：系统表空间
参数：innodb_data_file_path
（2）file-per-table tablespaces（每张表独立的表空间）
参数：innodb_file_per_table
（3）general tablespaces（通用表空间）
需要通过create tablespace语法创建通用表空间，在创建表时，可以指定该表空间。
语法：
create tablespace xxx add datafile ·file_name· engine = engine_name;
create table xxx tablespace ts_name;
cd /var/lib/mysql
（4）undo tablespace：撤销表空间
（5）temporary tablespace：临时表空间
（6）doublewrite buffer files：双写缓冲区
（7）redo log：重做日志
以循环方式写入重做日志文件，涉及两个文件：
4、后台线程
后台线程：在合适的时机，将InnoDB存储引擎缓冲池中的数据刷新到磁盘文件中。
（1）master thread
核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新、合并插入缓存、undo页的回收。
（2）IO Thread
在InnoDB存储引擎中大量使用了AIO来处理IO请求，可以极大地提高数据库的性能，而IO Thread主要负责这些IO请求的回调。
（3）Purge Thread
主要用于回收事务已经提交了的undo log，在事务提交之后，undo log可能不用了，就用它来回收。
（4）page cleaner thread
协助master thread刷新脏页到磁盘的现场，它可以减轻master thread的工作压力，减少阻塞。
三、事务原理
1、事务原理概述
事务特性：
2、redo log：重做日志
redo log实现持久性
当客户端发起事务操作时，先操作缓冲区，在缓冲区查找是否有我们要操作的数据，没有数据则通过后台线程去磁盘读取该数据，缓存在缓冲区中，进行增删改操作后，将增删改的数据直接写入redo log buffer，记录数据页变化，然后直接将其刷新在磁盘文件redo log file内。过段时间进行脏页刷新时，若程序出错，可通过redo log进行恢复。
为WAL（write-ahead logging）先写日志
每隔一段时间会清理redo log file，因此，这两个文件是循环写的。
3、undo log：回滚日志（Ctrl+Z）
undolog实现原子性
在进行update操作时，undo log记录更新前的数据。
undo log销毁：当我们在进行回滚操作后，undo log就没有用了，会进行销毁，但不会立即删除，因为还有可能用于MVCC（多版本并发控制）。
4、MVCC（多版本并发控制）
（1）基本概念
①当前读：
读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ... lock in share mode（共享锁），select ... for update、update、insert、delete（排他锁）都是一种当前读。
演示：
开启两个客户端，在第一个客户端执行select * from student;
在第二个客户端执行update操作：
此时在第一个客户端执行select * from student;无法查询到更新后的数据，第二个客户端commit;后也无法查询到更新后的语句，要读取最新的数据，即当前读，要执行select * from student lock in share mode;
②快照读
前文在第一个客户端执行select * from student;无法查询到更新后的数据，第二个客户端commit;后也无法查询到更新后的语句，即为快照读。
repeatable read：
在一个事务中第一次执行select * from student;为快照读的地方，后面执行的select * from student为读取前面的快照数据。
③MVCC（multi-version concurrency control）
三个隐式字段、undo log、readview
（2）MVCC-隐式字段
创建了一张表，含三个字段id、age、name，在InnoDB引擎中还会增加三个字段
使用ibd2sdi student.ibd查询表结构
可以看到两个隐式字段，由于这张表有主键，第三个隐式字段不会被自动创建
（3）MVCC-undo log
有数据如下所示：
要执行下面的事务：
首先要执行事务2，update操作，现在undo log日志中记录更新前的数据：
然后再修改数据;
同理执行事务2：
执行事务3：
undo log版本链：
（4）MVCC-readview
读取记录由readview决定
（5）MVCC-RC级别
每一次执行快照读时生成readview
分析事务5：
当第一次执行查询id为30的记录时，readview为如下所示：
由于事务2已经提交了，所以当前活跃事务为3,4,5
事务5要查询数据，快照读为他生成的，creator_trx_id=5
带入db_trc_id=4，都不行，沿着版本链带入db_trc_id=3，失败
带入=2时，满足第二条，查询到这条：
当第二次查询id为30的记录时，readview为如下所示：
依次带入：
查询到这条数据：
（6）MVCC-RR级别
RR隔离级别下，仅在事务第一次执行快照读时生成readview，后续复用该readview。
事务5中，两次查询id为30的记录，两次readview都如下所示：
规则和上面一样，两次查询到的为：