新版本结构演变

• MySQL 5.7 版本
  • 将 Undo日志表空间从共享表空间 ibdata 文件中分离出来，可以在安装 MySQL 时由用户自行指定文件大小和数量
  • 增加了 temporary 临时表空间，里面存储着临时表或临时查询结果集的数据
  • Buffer Pool 大小可以动态修改，无需重启数据库实例
• MySQL 8.0 版本
  • 将InnoDB表的数据字典和Undo都从共享表空间ibdata中彻底分离出来了，以前需要ibdata中数据字典与独立表空间ibd文件中数据字典一致才行，8.0版本就不需要了
  • temporary 临时表空间也可以配置多个物理文件，而且均为 InnoDB 存储引擎并能创建索引，这样加快了处理的速度
  • 用户可以像 Oracle 数据库那样设置一些表空间，每个表空间对应多个物理文件，每个表空间可以给多个表使用，但一个表只能存储在一个表空间中
  • 将Doublewrite Buffer从共享表空间ibdata中也分离出来了

InnoDB线程模型

InnoDB存储引擎是多线程的模型，因此其后台有多个不同的后台线程，负责处理不同的任务

后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。此外将已修改的数据文件刷新到磁盘文件，同时保证在数据库发生异常的情况下InnoDB能恢复到正常运行状态

• IO Thread

  在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来版本将read thread和write thread分别增大到了4个，一共有10个了

  show engine innodb status;
  

  

  • read thread(4个) ： 负责读取操作，将数据从磁盘加载到缓存page页
  • write thread(4个)：负责写操作，将缓存脏页刷新到磁盘
  • log thread(1个)：负责将日志缓冲区内容刷新到磁盘
  • insert buffer thread(1个) ：负责将写缓冲内容刷新到磁盘

• Purge Thread

  事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分配的undo页
  
  InnoDB1.2+开始，支持多个Purge Thread 这样做的目的为了加快回收undo页（释放内存）

• Page Cleaner Thread

  作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能达到redo log循环使用的目的。会调用write thread线程处理
  

• Master Thread

  Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数据异步刷新到磁盘 ，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别是每隔1秒和10秒处理

  每1秒的操作

  • 刷新脏页数据到磁盘，根据脏页比例达到75%才操作
    innodb_io_capacity用来表示IO的吞吐量，默认200，对于刷新到磁盘页的数量，会按照innodb_io_capacity的百分比来控制：

    • 在从缓冲池刷新脏页时，刷新脏页的数量为innodb_io_capcity
      

    • 如果缓冲池中的脏页比例大于innodb_max_dirty_pages_pct(默认是75%时),刷新脏页到磁盘数量是innodb_io_capacity的值
      

  • 合并写缓冲区数据: 并不是每秒刷新的，如果前一秒的IO次数小于5，则认为IO压力小，可以执行合并插入缓冲的操作

  • 刷新日志缓冲区到磁盘：即使事务没有提交，InnoDB也会每秒将重做日志缓冲刷新到重做日志文件中，因此可以理解为什么再大的事务提交，时间也是很短的

  每10秒的操作

  • 刷新脏页数据到磁盘
    • 从缓冲池刷新脏页时，刷行脏页的数量为innodb_io_capcity
  • 合并写缓冲区数据
    • 每隔10秒, 合并插入缓冲是innodb_io_capacity的5%
  • 刷新日志缓冲区(每隔10秒操作一次)
  • 删除无用的undo页(每隔10秒操作一次)