mysql面试（二）

news2024/11/15 11:10:00

前言

这是mysql面试基础的第二节，主要是了解一下mysql数据更新的基本流程，还有三大日志的作用。但是具体的比如undolog是如何应用在mvcc机制中的，由于篇幅问题就放在下一在章节

数据更新流程

上面是说了更新真正数据之前的大致流程，下面来说一下更新数据的时候具体会进行哪些操作。

InnoDB重要的内存结构：缓存池

首先是存储引擎访问数据的时候，并不会直接对磁盘进行操作，而是先在内存的缓存池中进行查询，如果查询不到的话再到磁盘中取拿数据，这样能减少大量磁盘的直接操作。
并且执行更新语句的时候，不仅要把数据更新到缓存池中，还需要对数据加独占锁，避免同时有其他数据来进行更新操作（这个独占锁包含行锁、间隙锁，后面再具体聊）

更新undo日志

undoLog起到最重要的作用就是记录数据更新之前的原始数据，以及该线程的事务（在mvcc机制中会用到）。举个栗子，比如我们要把id=1的数据中name=zhangsan 改为name=lisi。那么就需要吧id=1 name=zhangsan这个数据线记录下来，并且标记事务id。

更新buffer pool缓存页

前面的步骤已经拿出来数据，并且加了锁防止其他线程更新，原始数据也进行记录了。这时候就可以把缓存池中的数据进行修改了，把id=1这条数据的name字段修改为lisi。
这时候这条数据就属于一条脏数据，因为在内存中和磁盘中的数据不一致。

更新redoLog

现在已经对缓存中的数据进行了修改，并且记录了原始数据，这么多操作步骤，都需要记录到这个redoLog日志中，它是InnoDB的核心日志。更新的时候会在这个redo日志中新增记录一条“id=1的数据修改了name字段，值改为了lisi”类似这种形式的日志记录。
在当前步骤的所有操作都是在内存中，并没有进行磁盘的物理数据进行操作。所以这个时候也是不怕服务突然宕机断电之类的极端情况，因为如果宕机，内存丢失，对于磁盘数据也是没有任何影响的，下次查询的时候重新从磁盘中获取之前的数据就可以了。

binLog

在更新缓存数据和日志到磁盘之前，还有一个binLog日志也是需要了解的，虽然它记录的数据和redoLog很类似，也是“某个时刻对某某数据进行了某某操作”。但是它和redoLog最大的区别就是redoLog是InnoDB是引擎自己的组件，而binLog是mysql server自己的日志文件。

提交事务

进行了这么多步骤，终于要提交事务了。要提醒的一点是，undoLog、redoLog、binLog都是会在提交事务的这个步骤中写入磁盘中
什么时候更新进磁盘其实是可以配置的
根据innodb_flush_log_at_trx_commit来配置，它有几个选项
当值为0时：提交事务同时，redo日志不会写入磁盘，一旦mysql崩溃便会丢失
当值为1时：提交事务同时，redo日志写入磁盘。
当值为2时：提交事务同时，redo日志会先写入磁盘缓存os cache，过一段时间可能是一秒钟再写入磁盘

再次更新redoLog

在commit之后，会在redoLog日志中标记本次更新已经commit，并且会将本次更新对应的binLog文件名称和文件的位置都记录进redoLog中去。标记完mysql的IO线程会随机将缓存中修改后的数据刷进磁盘中
更新流程类如图：
在这里插入图片描述

三大日志

binlog

我们上面已经说了binLog存储的大致数据以及更新时间，其实他的更新策略也是可以修改的
数据同步会使用这个日志，可以扩展一下这一点。
syuc_binlog参数可以控制binlog的刷盘策略。
当值为0时：提交事务时只将binlog存入os cecha缓存
当值为1时：提交事务时会将binlog同步写入磁盘

redoLog

为什么要使用redo log，它可以保证我们在事务提交之后，哪怕缓存中更新的数据没有被刷新到磁盘上，也不会丢失，如果宕机了，根据redolog就可以恢复更新的缓存。
redo log本质上记录的就是在什么位置修改了什么值表空间号+数据页号+偏移量+修改几个字节的值+具体的值
redo log中有一个redo log block的概念，可以理解为是redo log日志的一个个子单元，每个有512字节，那么写入redo log的时候也是这样一个个小单元顺序放进去的；并且将redo log刷进磁盘的时候，也是按照这样一个个小单元更新的。
更新磁盘数据的时候，是先放在redo log buffer缓冲区的，每隔一定时间，把这些数据刷进磁盘中