目录与学习目标

  1. 1：Innodb引擎图解
  2. 2：undo_log redo_log  binlog （先了解）
  3. 3：执行器 
  4. 4：存在问题   
  5. 5：Mysql要设置这么一套复杂的机制来执行SQL了？

1：Innodb引擎图解

image.png

2：undo_log redo_log binlog （先了解）

  1. 1：如果是提交失败可以通过undo日志里面的数据恢复 BufferPool里面的缓存数据
  2. 2：如果事务提交成功 buffer pook里的数据还没来得及写入磁盘  此时系统宕机了
  3.     可以使用redo日志里面的数据恢复 buffer pool 里面的缓存数据
  4. 3：binlog主要是用来恢复数据库磁盘里的数据

3：执行器

  1. 原值HSJ
  2. 将要修改的值 hesuijin
  1. 执行sql：
  2. update tableName set name = 'hesujin' where id =1
  1. 1：从磁盘文件 加载到 缓存池（Buffer Pool）（里面是LRU算法 Least Recently Used）
  3.     加载缓存数据：
  4.     加载id为1的记录所在的整页数据
  6.     旧数据HSJ 加载到 缓存
  1. 2：写入更新数据的旧值从缓存中加载数据到undo日志（InnoDB独有）中
  3.     旧数据HSJ 加载到  undo日志文件
  1. 3：更新缓存数据
  3.    把旧数据HSJ 改成 新数据 hesuijin
  1. 4：写入Redo_Log Buffer （缓冲机制）
  3.    缓存机制存放 新数据hesuijin   后面批量的去写入磁盘
  1. 5：redo_log日志（InnoDB独有）写入磁盘
  3.     新数据 hesuijin写入到磁盘中
  5.     该redo_log的事务  prepare阶段  准备提交事务（二段提交 第一阶段）
  1. 6：bin_log日志（属于Server层  Myisam与InnoDB都有）写入磁盘
  3.     新数据 hesuijin写入到磁盘中
  1. 7：进行bin_log 与 redo_log 事务提交阶段
  2.     bin_log提交事务
  3.     写入commit标记 到 redo_bin日志文件里面  
  4.     该redo_log的事务 处于commit（二段提交 第二阶段）         
  5.     该标志保证事务提交后 redo 与binlog 数据一致
  1. 8：最终写入新数据真正写入磁盘
  3.     1：提交事务成功后 
  4.     2：Buffer Pool 的新数据  进入 IO 线程
  5.     3：IO线程 随机写入磁盘（随机刷盘）
  6.         （注意之前是读出一页的数据 这里面也是写入一页的数据）
  7.     4：刷盘完成 磁盘中的数据才真正变成  新数据 hesuijin

4：存在问题

  1. 问题1：为什么一定要保证 bin_log和redo_log 必须写完后   再进行提交事务？
  2.         因为提交事务就已经认为数据库的数据已经进行了修改。
  3.         redo_log日志文件：提交事务之后还没刷盘 在数据库重启之后会，redo_log日志文件恢复
  4.         bin_log日志文章：是需要保障数据恢复的  不可以缺少任何一条写记录的日志   
  6. 问题2：如果事务提交失败，会如何处理
  7.          特别注意：实际上事务真正意义上的提交是指：redo_log 和 bin_log的日志一起提交            
  8.          1：redo_log 与 bin_log 也会进行回滚
  9.          2：会使用undo_log 来恢复Buffer Pool缓存池的数据      
  10.          3：磁盘中的真正的数据还没继续修改  不需要处理

5：Mysql要设置这么一套复杂的机制来执行SQL了？

  1. 效率问题：内存肯定比硬盘快
  2. 数据库的增删改查都是直接操作Buffer Pool的，Buffer Pool一般设置为机器内存的60%左右
  1. 但日志文件也是写到磁盘里面的如何解释？
  3. 真正的答案是：磁盘的随机读写性能非常差 但磁盘顺序读写非常快   （相差2到3个数量级）
  5. 磁盘顺序IO的速度几乎可以与内存速度媲美
  7. redo_log是环型刷新   bin_log是文件追加   而mysql磁盘数据文件不一定连贯
  1. Msql存储数据的磁盘文件是在磁盘中随机读写
  3. 而redo_log 和 bin_log 是在磁盘中顺序读写
  1. Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，
  2. 然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。
  4. 更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。
  5. 正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。