视频课程
小黑屋思过中，禁止观看！
评论并刷新后可见

您需要在视频最下面评论并刷新后，方可查看完整视频

视频课程
立即观看
付费视频

您支付费用，方可查看完整视频

￥{{user.role.value}}
课程视频
开始学习
会员专享

视频合集

MySQL Innodb核心架构&SQL更新深度剖析

  • 课程笔记
  • 问答交流

前面我们系统了解了MySQL的架构以及一个SQL查询语句的执行全流程。通过一条SQL查询语句的执行过程：重点讲解了连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。

本节课会依然沿着这条主线，会重点会讲解到执行器与存储引擎是如何交互的，以及数据是如何存储落地的,以及对应的Innodb存储引擎相关的数据库参数调优。

我会重点讲解以下8点：

1.MySQL架构

2.InnoDB存储引擎架构

3.Buffer Pool

4.WAL crash-safe

5.Redo Log

6.Bin Log

7.SQL更新全过程解析

8.两阶段提交

本节课会讲解1个小时，请搬好小板凳开始了哦。

Innodb架构

MySQL Innodb核心架构&SQL更新深度剖析-mikechen

InnoDB 主要包括了内存池、后台线程以及存储文件。

1.缓冲池buffer pool

我们知道，如果客户端从数据库中读取数据是直接从磁盘读取的话，无疑会带来一定的性能瓶颈，缓冲池的作用就是提高整个数据库的读写性能。


 

评论交流
  1. mikechen

    ✗棒棒的✗ 很清晰

  2. 李鸿翼

    为什么写入redo log和 bin log要用两阶段提交？如果直接写入redo log，再去修改bin log，可能会出现什么问题？
    1.首先我们要知道这个两阶段提交是什么， 在数据库更新一条语句的时候，不会直接在磁盘修改数据，会把数据加载到缓冲池里进行修改，修改后，会把修改记录写到redo log buffer中， 当事务提交的时候，会把redo log buffer中的数据先刷到磁盘，这个为prepare阶段，然后写把binlog日志刷入磁盘，输入磁盘后，会把binlog名字以及写入磁盘位置写到redo log文件里，同时还写一个commit标记到到redo log你， 这次就是commit阶段。

    这么做的目的是为了保持这两个日志的数据一致性。

    2.如果不采用两阶段提交，先写redo log, 如果此时机器宕机了，binlog没写入进去。此时，重启机器，redo log把数据能恢复出来，但是Binlog没有，后续基于备份日志备份到其他库时，就不一致了。

  3. 路正银

    redolog是InnoDB引擎特有的日志系统，binlog是mysql数据库server层的日志
    redolog是为了减少磁盘IO次数，提高更新效率，采用WAL技术（先写日志，再写磁盘），是crash-safe的
    binlog日志用于归档，没有crash-safe能力
    采用两阶段提交，是为了两份日志之间的逻辑一致，保持数据一致性。
    先写redolog后写binlog：假设redolog写完，binlog还没有写完的时候，MySQL进程异常重启。可以利用redolog把数据恢复回来，但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。之后备份日志的时候，存起来的binlog里面就没有这条语句。如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，与原库的值不同。
    先写binlog后写redolog：如果在binlog写完之后crash，由于redolog还没写，崩溃恢复以后这个事务无效。但是binlog里面已经记录了这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，与原库的值不同。

    • mikechen

      是的，主要解决两份日志逻辑一致的问题，类似分布式事务的场景。
      与你下面谈到的一致，如果任何一个日志先写，在突发情况都会造成数据不一致的场景。
      所以需要两阶段来保证两个日志一致的问题。

❯
返回顶部