MySQL执行更新SQL流程

目录

[1 redo log](#1 redo log)

[2 binlog](#2 binlog)

[3 Update执行逻辑](#3 Update执行逻辑)


1 redo log
  • InnoDB引擎特有日志
  • MySQL的WAL(Writing Ahead logging)技术,预写式日志,先写日志再写磁盘
  • 当有一条记录需要更新时,InnoDB引擎就会先把记录写在redo log日志中,然后在后面系统比较空闲的时候,将这个操作记录更新到磁盘里面
  • 记录的是物理日志,在某个数据页上做了什么修改
  • 空间大小固定,循环写入

redo日志相关配置

  • innodb_log_file_size:配置单个redo日志文件大小
  • innodb_log_files_in_group:配置redo日志文件个数
  • innodb_log_buffer_size:redo日志内存缓冲区大小
  • innodb_flush_log_at_trx_commit:redo日志缓冲区数据落盘时机
    • 0:每秒将redo日志缓冲区内容写入到文件系统缓存,再同步到磁盘
    • 1:每次提交时立即将redo日志缓冲区内容写入到文件系统缓存,再同步到磁盘
    • 2:每次提交立即将redo日志缓冲区内容写入到文件系统缓存,不立即同步到磁盘,由操作系统决定何时同步到磁盘
  • write pos是当前记录的位置,一边写一边后移,写到3号文件结尾时,就回到0号文开头
  • checkpoint是当前要同步磁盘的开始位置,边将数据同步到磁盘一边向后移动
  • wirte position和checkpoint之间是空闲位置,可以用来记录更新操作
  • 当wirte position追上checkpoint时,得先推进下checkpoint位置,才能继续写更新记录
  • redo log可以保证在数据库发生异常的情况下重启,之前提交的记录都不会丢失,这个能力称之为crash-safe
2 binlog
  • MySQL Server层的日志,也称为归档日志
  • 所有的存储引擎都可以使用
  • 主要用于归档,是逻辑日志,记录的是SQL语句
  • 追加写入,达到设置阈值时,切换新的binlog文件

binlog日志相关配置

  • server-id:开启binlog时,必须设置的唯一id
  • log-bin:配置binlog文件路径和前缀
  • binlog-format:指定binlog日志的格式
    • ROW:记录每一行的变化,占用空间大,但是记录的数据完整准确
    • STATEMENT:记录执行的SQL语句,sql中包含函数执行时会导致主从数据不一致问题
    • MIXED:根据情况自动选择ROW或者STATEMENT

expire_logs_day:设置binlog日志文件的保留天数,默认0,表示不删除旧的日志文件

max_binlog_size:设置单个binlog日志文件的最大大小,当达到该值时,会生成一个新的日志文件

binlog日志的操作

  • show master status:查看当前的日志文件及位置
  • purge binary logs:手动清理日志文件
    • purge binary logs to 'mysql-bin.0000010':删除到指定文件之前的日志
    • purge binary logs before '2025-03-01 00:00:00':删除到指定日期之前的日志
  • show binary logs:查看binlog日志文件列表
  • show binlog events:查看第一个binlog日志内的事件
  • show binlog events in 'mysql-bin.0000010':查看指定binlog日志文件中的事件

binlog解析的工具

  • mysqlbinlog
  • binlog2sql
3 Update执行逻辑

执行update语句内部流程

  • 执行器向存储引擎获取id=1的这一行,
  • 存储引擎使用索引树进行查找,如果id=1这一行所在的数据页本来就在内存中,就直接返回给执行器,否则先从磁盘读入内存,然后在返回
  • 执行器拿到存储引擎给的数据,将name设置为lose,得到新的一行数据,再调用存储引擎写入这行数据
  • 存储引擎将更新后的数据更新到内存中,同时将更新操作记录到redo log中,此时redo log处于prepare状态,告知执行器执行完了,随时可以提交事务
  • 执行器生成这个操作的binlog,并把binlog写入磁盘
  • 执行器调用存储引擎提交事务的接口,将刚刚写入的redo log改成提交(commit)状态,此时更新完成

执行更新流程图

MySQL两阶段提交

  • prepare阶段
    • 将数据写入redo log
    • 将数据写入binlog
  • commit阶段
    • binlog中提交commit请求
    • 调用innodb引擎发送commit请求

那么MySQL如何识别哪些提交属于一个事务呢?

  • 在redo log和binlog中,都包含xid信息,xid是事务id,在MySQL实例中是全局唯一的。

崩溃恢复如何做呢?

  • redo log中事务是完成的,即已经有了commit标识,则直接提交事务
  • redo log中只有完整的prepare,没有commit标识,此时需要在binlog中查找
    • 如果binlog中已经commit,则提交事务
    • 如果binlog没有commit,则回滚事务
相关推荐
爱编程的王小美14 分钟前
本地MySQL连接hive
数据库·hive·mysql
珹洺18 分钟前
数据库系统概论(七)初识SQL与SQL基本概念
数据库·sql
云计算DevOps-韩老师38 分钟前
精品,架构师总结,MySQL 5.7 查询入门详解
数据库·mysql
Estrella-q40 分钟前
解决 Ubuntu DNS 无法解析问题(适用于虚拟机 & 长期使用)
数据库·ubuntu·postgresql
didiplus1 小时前
MySQL 8.0 OCP(1Z0-908)英文题库(1-10)
mysql·adb·ocp·数据库管理员·mysql认证
凡梦千华1 小时前
在一台CentOS服务器上开启多个MySQL服务
服务器·mysql·centos
进击的CJR1 小时前
MySQL 8.0 OCP 英文题库解析(二)
android·mysql·开闭原则
TDengine (老段)1 小时前
TDengine 在智慧油田领域的应用
大数据·数据库·物联网·时序数据库·iot·tdengine·iotdb
二十雨辰1 小时前
[Spring]-认识Spring
java·数据库·spring
苹果酱05672 小时前
[数据库之十一] 数据库索引之联合索引
java·vue.js·spring boot·mysql·课程设计