MySQLinnodb引擎深入讲解

　　一、逻辑存储结构
　　表空间（ibd文件），一个MySQL实例可以对应多个表空间，用于存储记录，索引等数据。
　　段，分为数据段、索引段、回滚段，innodb是索引组织表，数据段就是BTree的叶子节点，索引段为非叶子节点，段用来管理多个区。
　　区，表空间的单元结构，每个区的大小为1M，默认情况下，innodb存储引擎页大小为16K，即一个区中一共有64个连续的页。
　　页，是innodb存储引擎磁盘管理的最小单元，每个页的大小为16K，为了保证页的连续性，innodb存储引擎每次从磁盘申请45个区。
　　行，innodb存储引擎数据是按行进行存储的。Trxid最后一次事务操作的id、rollpointer滚动指针。
　　innodb的内存结构，由BufferPool、ChangeBuffer和LogBuffer组成。
　　BufferPool：缓冲池是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池么有数据，则从磁盘加载并缓存），然后再以一定频率刷新磁盘，从而减少磁盘IO，加快处理速度。
　　缓冲池以page页为单位，底层采用链表数据结构管理page，根据状态，将page分为三种类型：
　　1、freepage即空闲page，未被使用。
　　2、cleanpage被使用page，数据没有被修改过。
　　3、dirtypage脏页，被使用page，数据被修改过，这个page当中的数据和磁盘当中的数据不一致。说得简单点就是缓冲池中的数据改了，磁盘中的没改，因为还没刷写到磁盘。
　　ChangeBuffer：更改缓冲区（针对于非唯一二级索引页），在执行DML语句时，如果这些数据page没有在BufferPool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区ChangeBuffer中，在未来数据被读取时。再将数据合并恢复到BufferPool中，再将合并后的数据刷新到磁盘中。
　　二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引页，同样，删除和更新可能会影响索引树中不相邻的二级索引页。如果每一次都操作磁盘，会造成大量磁盘IO，有了ChangeBuffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO。
　　AdaptiveHashIndex：自适应hash索引，用于优化对BufferPool数据的查询，InnoDB存储引擎会监控对表上各索引页的查询，如果观察到hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。无需人工干预，系统根据情况自动完成。
　　参数：VariablenameValueinnodbadaptivehashindexONinnodbadaptivehashindexparts82rowsinset（0。01sec）
　　LogBuffer：日志缓冲区，用来保存要写入到磁盘中的log日志数据（redolog、undolog），默认大小为16M，日志缓冲区的日志会定期刷新到磁盘中，如果需要更新，插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘IO。
　　参数：innodblogbuffersize缓冲区大小
　　innodbflushlogattrxcommit日志刷新到磁盘时机
　　innodbflushlogattrxcommit1表示日志在每次事务提交时写入并刷新到磁盘
　　2表示日志在每次事务提交后写入，并每秒刷新到磁盘一次
　　0表示每秒将日志写入并刷新到磁盘一次。
　　InnoDB的磁盘结构，由系统表空间（ibdata1），独立表空间（。ibd），通用表空间，撤销表空间（undotablespaces），临时表空间（TemporaryTablespaces），双写缓冲区（DoublewriteBufferfiles），重做日志（RedoLog）。
　　系统表空间（ibdata1）：系统表空间是更改缓冲区的存储区域，如果表是在系统表空间而不是每个表文件或者通用表空间中创建的，它也可能包含表和索引数据。
　　参数为：innodbdatafilepath
　　独立表空间（。ibd）：每个表的文件表空间包含单个innodb表的数据和索引，并存储在文件系统上的单个数据文件中。参数：innodbfilepertable
　　通用表空间：需要通过createtablespace语法创建，创建表时可以指定该表空间。
　　createtablespacexxxadddatafilefilenameengineenginename
　　createtabletablename。。。。tablespacexxx
　　撤销表空间（undotablespaces）：MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16K，undo001，undo002），用于存储undolog日志
　　临时表空间（TemporaryTablespaces）：innodb使用会话临时表空和全局表空间，存储用户创建的临时表等数据。
　　双写缓冲区（DoublewriteBufferfiles）：innodb引擎将数据页从BufferPool刷新到磁盘前，先将数据页写入缓冲区文件中，便于系统异常时恢复数据。
　　重做日志（RedoLog）：是用来实现事务的持久性，该日志文件由两部分组成，重做日志缓冲区（redologbuffer）以及重做日志文件（redolog），前者是在内存中，后者在磁盘中，当事务提交之后会把修改信息都会存储到该日志中，用于在刷新脏页到磁盘时，发送错误时，进行数据恢复使用。以循环方式写入重做日志文件，涉及两个文件iblogfile0，iblogfile1。
　　那内存结构中的数据是如何刷新到磁盘中的？在MySQL中有4个线程负责刷新日志到磁盘。
　　1、MasterThread，mysql核心后台线程，负责调度其它线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新，合并插入缓冲、undo页的回收。
　　2、IOThread，在innodb存储引擎中大量使用了AIO来处理IO请求，这样可以极大地提高数据库的性能，而IOThead主要负责这些IO请求的回调。
　　4个读线程Readthread负责读操作
　　4个写线程writethread负责写操作
　　1个Logthread线程负责将日志缓冲区刷新到磁盘
　　1个insertbuffer线程负责将写入缓冲区内容刷新到磁盘
　　3、PurgeThread，主要用于回收事务已经提交了的undolog，在事务提交之后，undolog可能不用了，就用它来回收。
　　4、PageCleanerThread，协助MasterThread刷新脏页到磁盘的线程，它可以减轻主线程的压力，减少阻塞。
　　事务原理
　　事务就是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失效。
　　事务的4大特性分为：原子性atomicty：事务是不可分割的最小操作单元，要么全部成功，要么全部失效。一致性consistency：事务完成时，必须使所有的数据都保持一致状态。隔离性isolation：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。持久性durability：事务一旦提交或回滚，它对数据库中的改变就是永久的。
　　如何保证事务的4大特性，原子性，一致性和持久性是由innodb存储引擎底层的两份日志来保证的，分别是redolog和undolog。对于隔离性是由锁机制和MVCC（多版本并发控制）来实现的。
　　redolog，称为重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲redologbuffer及重做日志文件redologfile，前者是在内存中，后者是在磁盘中，当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发送错误时，进行数据的恢复使用，从而保证事务的持久性。
　　具体的操作流程是：
　　1、客户端发起事务操作，包含多条DML语句。首先去innodb中的bufferpool中的数据页去查找有没有我们要更新的这些数据，如果没有则通过后台线程从磁盘中加载到bufferpool对应的数据页中，然后就可以在缓冲池中进行数据操作了。
　　2、此时缓冲池中的数据页发生了变更，还没刷写到磁盘，这个数据页称为脏页。脏页不是实时刷新到磁盘的，而是根据你配置的刷写策略进行刷写到磁盘的（innodbflushlogattrxcommit，0，1，2三个值）。如果脏页在往磁盘刷新的时候出现了故障，会丢失数据，导致事务的持久性得不到保证。为了避免这种现象，当对缓冲池中的数据进行增删改操作时，会把增删改记录到redologbuffer当中，redologbuffer会把数据页的物理变更持久化到磁盘文件中（iblogfile0iblogfile1）。如果脏页刷新失败，就可以通过这两个日志文件进行恢复。
　　undolog，它是用来解决事务的原子性的，也称为回滚日志。用于记录数据被修改前的信息，作用包括：提供回滚和MVCC多版本并发控制。
　　undolog和redolog的记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undolog中会记录一条对应的insert记录，当update一条记录时，它记录一条对应相反的update记录，当执行rollback时，就可以从undolog中的逻辑记录读取到相应的内容并进行回滚。
　　undolog销毁：undolog在事务执行时产生，事务提交时，并不会立即删除undolog，因为这些日子可能用于MVCC。
　　undolog存储：undolog采用段的方式进行管理和记录，存放在前面介绍的rollbacksegment回滚段中，内部包含1024个undologsegment。MVCC
　　mvcc（multiVersionConcurrencyControl），多版本并发控制，指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能，MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段，undolog日志、readView。当前读，指的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如selectlockinsharemode，selectforupdate、update、insert、delete都是一种当前读。快照读，简单的select（不加锁）就是快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁是非阻塞读。
　　readcommitted每次select都生成一个快照读
　　repeatableread开启事务后第一个select语句才是快照读的地方
　　serializable快照读会退化为当前读。
　　mvcc的实现原理记录中的隐藏字段DBTRXID、DBROLLPTR、DBROWID（ibd2sdistu。ibd查看表空间）
　　DBTRXID：最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID
　　DBROLLPTR：回滚指针，指向这条记录的上一个版本，用于配合undolog，指向上一个版本
　　DBROWID：隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。undolog回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志，当insert的时候，产生的undolog日志只在回滚时需要，在事务提交后可以立即删除。而update、delete的时候，产生的undolog日志不仅仅在回滚时需要，在快照读时也需要，不会立即被删除。undolog版本链，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。readView（读视图），就是快照读SQL执行时mvcc提取数据的依据，记录并维护系统当前活跃的事务（为提交的）ID，readview中包含了四个核心字段。
　　mids当前活跃的事务ID集合
　　mintrxid：最小活跃事务id
　　maxtrxid：预分配事务ID，当前最大事务id1，因为事务id是自增的
　　creatortrxid：ReadView创建者的事务ID
　　版本链数据访问规则：
　　trxid：表示当前的事务ID
　　1、trxidcreatortrxid？可以访问读版本成立的话，说明数据是当前这个事务更改的
　　2、trxidmintrxid？可以访问读版本成立，说明数据已经提交了。
　　3、trxidmaxtrxid？不可用访问读版本成立的话，说明该事务是在ReadView生成后才开启的。
　　4、mintrxidtrxidmaxtrxid？如果trxid不在mids中是可以访问读版本的成立的话，说明数据已经提交。
　　不同的隔离级别，生成ReadView的时机不同：
　　readcommitted：在事务中每一次执行快照读时生成ReadView
　　repeatableread：仅在事务中第一次执行快照读时生成readview，后续复用度readview。
　　小结：
　　1、innodb的逻辑存储结构：表空间、段、页、行
　　2、innodb的架构由内存结构和磁盘结构组成
　　3、事务原理：原子性undolog实现
　　持久性redolog实现
　　一致性undolog加redolog
　　隔离性锁加mvcc
　　4、mvcc，记录隐藏字段，undolog版本链，readView