存储引擎：

MySQL中具体与文件系统打交道的子系统；根据MySQL AB公司提供的文件访问层抽象接口定制的一种文件访问机制

存储引擎分类：

  • MyISAM——最古老
  • InnoDB——支持事务。5.6之后的默认引擎
  • Memory、NDB——内存类型
  • Archive——归档类型
  • RocksDB等

功能对比：

image.png

InnoDB部分特性：

image.png

InnoDB核心特性：

image.png

InnoDB存储引擎体系结构：

image.png

InnoDB存储引擎体系结构-实例层：

master thread：负责调度其他各线程，内部包含主线程(1s和10s)、后台迅和、刷新循环
buf dump thread：负责把buffer pool中的内容dump到物理文件中，以便再次启动MySQL时 快速加热数据
page cleaner thread：负责把buffer pool中的脏页刷新到磁盘(5.7版本之后出现的线程，5.6及之前都是由主线程master thread完成，所以5.6及之前版本刷脏页非常耗费性能)
purge thread：负责将不再使用的undo日志进行回收
read thread：处理用户的读请求，并负责将数据页从磁盘上读处理放入内存的buffer pool
write thread：负责将数据页从缓冲区写到磁盘
redo log thread：负责把日志缓冲中的内容刷新到redo log文件中
insert buffer thread：负责把insert buffer中的内容刷新到磁盘

Buffer Pool：包含数据和索引页、undo页、insert buffer页、自适应hash索引页、数据字典页和锁信息等
redo log buffer：存储数据修改所产生的redo log
doubule write buffer：主要解决由于宕机引起物理写入操作中断、数据不完整的情况
image.png

主循环的两种操作：1s

image.png

主循环的两种操作：10s

image.png

InnoDB存储引擎体系结构-物理层：

image.png
系统表空间：ibdata文件(insert buffer段、doubule write段、回滚段、索引段、数据字典段和undo信息段)、undo文件
用户表空间：.ibd后缀的文件，里面包含insert buffer的bitmap页、叶子页、非叶子页
redo日志：包含多个redo日志文件。循环使用，当使用比例达到一定阈值时会触发check pointer 刷脏操作，同时也在MySQL宕机重启时表数据自动还原

MySQL5.6的InnoDB存储引擎结构：

image.png
BufferPool决定了一条SQL的执行快慢
用户读取或写入最新数据，都是在Buffer Pool中，如果BufferPool中没有，则会读取物理文件从中查找，并将数据加载到BufferPool中
BufferPool采用LRU方式淘汰BufferPool中的数据

image.png
redo log记录所有对BufferPool的物理修改日志。 redo log的检查点lsn和新写入的文件的lsn差值>=75%触发异步刷盘async flush checkpoint；当>=90%触发同步刷盘sync flush checkpoint
redo log 作用—-保证事务的持久性

MySQL5.7的变化：

  • 之前版本redo log大小不能超过3GB，5.7之后无限制
  • 将undo log从ibdata文件中分离出来，可以在安装MySQL时自行指定文件大小和数量
  • 增加了Temporary临时表空间，用于存储临时表、或者临时查询结果集数据
  • BufferPool大小可以动态修改，无需重启数据库实例

image.png

MySQL8.0变化：

  • 将数据字典和undo 都从共享表空间ibdata中彻底分离
  • Temporary临时表空间可以配置多个物理文件

image.png

InnoDB核心特性——ARIES三原则

image.png