mysql InnoDB架构

1、InnoDB的磁盘结构
1）系统表空间
2）用户表空间
3）rodolog 文件组
4）磁盘文件逻辑结构
文件->段->区->页->行
InnoDB对数据的存取是以页为单位的，一个数据页默认是16k
2、InnoDB的内存结构
1）buffer pool
1.数据页
2.索引页
3.ChangeBuffer修改缓冲区（InsertBuffer插入缓冲区）
为了提高辅助索引（非聚集索引，除主键之外的索引）更新性能，暂时先把辅助索引的更新内容写到ChangeBuffer中。后台有线程定时更新。
4.自适应hash索引
为了提高查询性能，由InnoDB自己维护了一个hash索引。用户无法干预。
参考：https://juejin.im/post/6847902217270198286
5.锁信息和数据字典
2）redo log buffer重做日志缓冲区
1.redolog是一个顺序写的日志文件。wal（write ahead log）模式。顺序写比随机写效率要高。使用redo log暂存提交成功的数据。如果一旦系统崩溃，可以使用redo log恢复数据。
2.redo log buffer就是一个缓冲区，定时将缓冲区的数据保存到磁盘。
默认1s保存一次。默认在执行commit操作之前刷新redo log buffer。

	参数：innodb_flush_log_at_trx_commit控制redo log的落盘时机
		* 当属性值为0时，事务提交时，不会对重做日志进行写入操作，而是等待主线程按时写入每秒写入一次；
		* 当属性值为1时，事务提交时，会将重做日志写入文件系统缓存，并且调用文件系统的fsync，将文件系统缓冲中的数据真正写入磁盘存储，确保不会出现数据丢失；
		* 当属性值为2时，事务提交时，也会将日志文件写入文件系统缓存，但是不会调用fsync，而是让文件系统自己去判断何时将缓存写入磁盘。
3）双写缓冲区
	数据落盘需要执行双写操作，需要使用到双写缓冲区。稍后详解。

3、数据落盘
1）脏页
当更新数据commit之后，数据不是马上更新到磁盘。把数据更新到缓冲池中对应的数据页和索引页中。此时就会造成内存中的数据页和索引页与磁盘上的数据页不一致，就形成了脏页。
2）CheckPoint
执行脏页落盘操作的。
sharp checkpoint：在关闭数据库的时候，将buffer pool中的脏页全部刷新到磁盘中
fuzzy checkpoint：模糊落盘
1、Master Thread Checkpoint；
会以每秒或者每10秒一次的频率，将部分脏页从内存中刷新到磁盘，参数可调。
2、FLUSH_LRU_LIST Checkpoint；
使用LRU算法需要把一些数据页移除，但是数据页是脏页，需要执行checkpoint。
3、Async/Sync Flush Checkpoint；
redo log文件快写满时。
Async：当需要落盘的日志超过日志文件的75%并且小于90%时。
sync：当需要落盘的日志超过日志文件超过90%时。
4、Dirty Page too much Checkpoint
bufferPool缓冲池脏页太多
Dirty Page 由[innodb_max_dirty_pages_pct]配置，innodb_max_dirty_pages_pct的默认值在innodb 1.0之前是90%，之后是75%
3）双写落盘double write
当脏页落盘过程中，是使用双写操作执行落盘的。
1.把要落盘的数据写先写入双写缓冲区2m大小的双写缓冲区。
2.把双写缓冲区的数据写入系统表空间中的双写区。
3.把双写缓冲区的数据写入用户表空间中。

	redolog中记录的是数据页中修改了哪些内容，并不是完整的数据页。
	
	场景1：系统表空间中的数据页写坏了，可以通过用户表空间的数据页+redolog恢复。
	场景2：系统表空间中的数据页写完了，用户表空间写坏了。可以通过系统表空间的数据页恢复。

	通过双写机制保证数据落盘过程万无一失。