mysql InnoDb引擎
1.逻辑存储结构
1.区，表空间的单元结构，每个区的大小为1M，每个页的大小默认为 16KB，一个区中一共有64个连续的页
2.InnoDB存储引擎在分配空间时一次性申请4-5个区从而保证申请到的页是连续的
2.架构
MySQL5.5版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，在日常开发中使用广泛。下图是InnoDB架构图，左侧为内存结构，右侧为磁盘结构。
2.1、内存结构
1).Buffer pool(缓冲池)：在执行增删改查操作时，先操作缓冲池中的数据，(缓冲池没有数据，再去磁盘加载并缓存在缓冲池中)，然后再以一定的频率刷新到磁盘中，减少磁盘IO，加快处理速度。
缓冲池以page为单位，底层采用链表数据结构管理page。
2).Change Buffer:更改缓冲区（针对于非唯一二级索引页），在执行DML语句时，如果这些数据Page没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区Change Buffer中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。
3).Adaptive Hash Index：自适应hash索引，用于优化buffer pool数据的查询。
4).log buffer：日志缓冲区。用来保存要写入磁盘的log日志（redo log、undo log），默认为16M，日志缓冲区的日志会定期刷新到磁盘。可以通过增加日志缓冲区的大小来减少磁盘IO。
参数：
innodb_log_buffer_size：缓冲区大小
innodb_flush_log_at_trx_commit：日志刷新到磁盘时机（0：每次事务提交时刷新到磁盘；1：每秒刷新到磁盘；2：日志在每次事务提交后写入，并每秒刷新到磁盘）。
对于一个专门的数据库服务器来说会把80%左右的内容分配给缓存区，通过缓存区可以提高数据库的并发访问性能
2.2、磁盘结构
1).system tablespace:系统表空间是更改缓冲区的存储区域。参数：innodb_data_file_path
2).file-per-table tablespace：每个表的文件表空间包含单个InnoDB表的数据和索引，并存储在文件系统上的单个数据文件(.idb)中.参数：innodb_file_per_table 默认开启
3).general tablespaces：通用表空间，默认不存在，但可以手动创建，手动指定关联。
创建通用表空间： create tablespace ts_name add dataile 'file_name' engine=engine_name;
关联通用表空间： create table xxx tablespace ts_name;
4).doublewrite buffer files:双写缓冲区。InnoDB引擎将数据页从buffer pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据。
5).undo tablespace：撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（大小默认16M），用于存储undo log。
6).temporary tablespaces：临时表空间，用于存放临时表等数据。
7).redo log：重做日志，用来实现事务的持久性。当事务提交之后，会把所有修改信息都存到该日志中，用于在刷新脏页(内存结构数据与磁盘数据不一致)到磁盘发生错误时，进行数据恢复使用。
以循环方式写入重做日志文件，涉及两个文件：
2.3、后台线程
内存结构的数据是通过后台线程刷新到磁盘结构的
作用：InnoDb存储引擎缓冲池的数据在合适的时机刷新到磁盘文件中
4类线程：
1.Master Thread（主线程）
核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新、合并插入缓存、undo页的回收。
2.IO Thread
在InnoDB存储引擎中大量使用了AIO（异步非阻塞IO）来处理IO请求，这样可以极大地提高数据库的性能，而IOThread.主要负责这些O请求的回调。
3.Purge Thread
主要用于回收事务已经提交了的undo log(撤销日志),在事务提交之后，undo log可能不用了，就用它来回收
4.Page Cleaner Thread
协助Master Thread刷新脏页到磁盘的线程，它可以减轻Master Thread的工作压力，减少阻塞。
总结：
InnoDB存储引擎体系结构：
业务在操作时会直接操作缓存区，若缓存区没有数据会从磁盘中加载数据到缓存区并存储，我们在做增删改查时会操作缓存区，缓存区的数据会以一定的时机通过线程刷新到磁盘中进行永久化保留下来（表中数据、索引永久化保留，undo tablespace、redo log是需要回收及释放对应的磁盘空间）
3.事务原理
事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。
特性：原子性、一致性、隔离性、持久性
对于事务的原子性、一致性、持久性是通过INnoDB存储引擎底层的redo.log（记录物理日志）、undo.log（记录逻辑日志）来保障的，对于隔离性是由INnoDB存储引擎底层的锁机制和MVCC(多版本并发控制)来实现的
3.1 redo.log
通过redo.log来解决事务的持久性
重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲(redo log buffer，存放在内存中)以及重做日志文件(redo log file，存放在磁盘中)。当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发生错误时，进行数据恢复使用。
3.2 undo.log
通过undo.log来解决事务的原子性
回滚日志，用于记录数据被修改前的信息，作用包含两个：提供回滚和MVCC(多版本并发控制)。redo log记录物理日志，undo log记录逻辑日志。可以认为:当delete一条记录时，undo log中会记录一条对应的insert记录，当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log,因为这些日志可能还用于MVCC。
undo log存储：undo log:采用段的方式进行管理和记录，存放在前面介绍的rollback segment回滚段中，内部包含1024个undo log segment
通过redo.log + undo.log来解决事务的一致性
4.MVCC
基本概念：
当前读: 读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作. 如：select ... lock in share mode(共享锁)，select ... for update、update、insert、delete(排他锁)都是一种当前读。
eg:两个终端同时开启事务，事务1执行查询操作，事务2执行更新操作并提交事务，事务1要想查询到事务2的提交数据需要执行select ... lock in share mode
快照读: 简单的select(不加锁)就是快照读，快照读读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
- Read Committed:每次select,都生成一个快照读。
- Repeatable Read:开启事务后第一个select语句才是快照读的地方。
- Serializable:快照读会退化为当前读。
MVCC: 多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现。MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
作用：在快照读时通过MVCC来查找对应的历史版本
4.1 三个隐式字段
4.2 undo log版本链
不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。
4.3 readview
ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。
不同的隔离级别，生成ReadView的时机不同：
（1）READ COMMITTED （RC隔离级别）：在事务中每一次执行快照读时生成ReadView。
（2）REPEATABLE READ（RR隔离级别）：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。
