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,则回滚事务
相关推荐
zxrhhm16 分钟前
SQLServer限制特定数据库的CPU使用率,确保关键业务系统有足够的资源
数据库·sqlserver
刘~浪地球39 分钟前
Redis 从入门到精通(十三):哨兵与集群
数据库·redis·缓存
Java开发追求者1 小时前
windows卸载mysql教程
mysql·mysql卸载
dyyshb1 小时前
PostgreSQL 终极兜底方案
数据库·postgresql
他们叫我技术总监1 小时前
零依赖!FineReport11 快速对接 TDengine 数据库:从驱动部署到报表实现
大数据·数据库·ai·tdengine
TDengine (老段)1 小时前
TDengine IDMP 可视化 —— 定时报告
大数据·数据库·人工智能·物联网·时序数据库·tdengine·涛思数据
曹牧2 小时前
Oracle:
数据库·oracle
kobel282 小时前
Linux x86快速部署openGauss3.1.1指南
数据库
草莓熊Lotso2 小时前
【Linux 线程进阶】进程 vs 线程资源划分 + 线程控制全详解
java·linux·运维·服务器·数据库·c++·mysql
supericeice2 小时前
创邻科技 Galaxybase Graph Intelligence 图智能平台:一站式可视化图数据存储、图计算与图挖掘平台
数据库·科技