剖析 MySQL的 undo log

最新推荐文章于 2025-12-20 14:42:23 发布
原创 最新推荐文章于 2025-12-20 14:42:23 发布 · 1k 阅读 · 22 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #数据库 #学习 #java #程序人生

本文详细介绍了MySQLInnoDB引擎中的undolog日志，包括其概念、在事务回滚和MVCC中的作用，以及undolog的生成时机、存储位置和结构。还通过实战案例解析了事务回滚的过程和MVCC的工作原理。

今天这篇文章给大家带来MySQL中另外一个重要的日志 - undo log。

文章导读

概念

undo log是innodb引擎的一种日志，在事务的修改记录之前，会把该记录的原值（before image）先保存起来（undo log）再做修改，以便修改过程中出错能够恢复原值或者其他的事务读取。

作用

从概念的定义不难看出undo log的两个作用：

  1. 事务回滚 - 原子性： undo log是为了实现事务的原子性而出现的产物，事务处理的过程中，如果出现了错误或者用户执行ROLLBACK语句，MySQL可以利用undo log中的备份将数据恢复到事务开始之前的状态。

  2. 多个行版本控制（MVCC）- 隔离性： undo log在MySQL InnoDB储存引擎中用来实现多版本并发控制，事务未提交之前，当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。

什么时候会生成undo log

在事务中，进行以下四种操作，都会创建undo log：

  1. insert用户定义的表

  2. update或者delete用户定义的表

  3. insert用户定义的临时表

  4. update或者delete用户定义的临时表

存放在哪里？

既然是一种日志，储存在什么目录？ 又是怎样储存的？

储存在什么目录？

这里要需要说明一下，在MySQL5.6.3之前的版本中，这个undo tablespace是和system tablespace系统表空间存放在一起的，也就是没有单独的undo log文件，直接存放在ibdata1文件里边，在MySQL5.6.3之后的版本中，MySQL支持将undo log tablespace单独剥离出来，但这个特性依然很鸡肋：

  1. 要在安装数据库的时候，就指定好独立undo tablespace，在安装完成后不可更改；

  2. undo tablespace的space id必须从1开始，无法增加或者删除undo tablespace；

特意安装了MySQL5.6.39验证一波：

到了MySQL5.7版本，终于引入期待已久的功能：即在线truncate undo tablespace（解决了第一个鸡肋点，可以在安装数据库之后更改undo tablespace）

在MySQL8.0中，InnoDB再进一步，对undo log做了进一步的改进：

  1. 从8.0.3版本开始，默认undo tablespace的个数从0调整为2，也就是在8.0版本中，独立undo tablespace被默认打开。修改该参数为0会报warning并在未来不再支持；

  2. 无需从space_id 1开始创建undo tablespace，这样解决了In-place upgrade或者物理恢复到一个打开了Undo tablespace的实例所产生的space id冲突。不过依然要求undo tablespace的space id是连续分配的；

根据官方的MySQL结构图，我画了MySQL的结构简图，描述了undo log在数据库磁盘中的位置，只需要关注简图中画红色方框和绿色方框的模块。

最低0.47元/天 解锁文章
MySQL中Undo Log及MVCC
chengwe17的博客
04-01 1596
InnoDB存储引擎数据库会 隐藏的为数据添加DB_TRX_ID（事务ID）、DB_ROLL_PTR（回滚指针）、DB_ROW_ID（聚簇索引）。（了解MVCC只需要了解这三个隐藏字段即可）DB_TRX_ID（事务ID）：表示最近一次对当前行数据做修改（insert、update）的事务ID，Delete操作在MySQl中它属于Update，事务ID是自增的。Undo Log中数据记录的多个版本之间，使用回滚指针进行连接。数据表中如果没有主键，且没有非空唯一主键情况下，这个字段会被作为表的聚簇索引。
MySQL日志篇之undo-log、redo-log、bin-log
vbgesab的博客
07-14 1107
叨叨絮絮下来，就大致将MySQL中的一些常见、较为重要的日志讲明白啦，其实重点搞清楚即可，其他的会在后续篇章中再次提到，最后稍微总结一下这三个比较核心的日志：•undo-log：主要用于实现事务ACID原则中的原子性和MVCC机制。•redo-log：主要用于实现事务原则中的持久性，确保事务提交后就不会丢失。•bin-log：主要结合redo-log实现事务原则中的一致性，确保事务提交前后，数据的一致。
MySQL redo和undo日志详解 | 学习笔记
qq_41523340的博客
03-12 4701
为什么需要redo日志和undo日志呢？我们知道事务有四个特征：原子性，一致性，隔离性，持久性。隔离性由锁机制实现，其他三种特性是由redo日志和undo日志来实现的。 REDO LOG称为重做日志， 1. redo日志 二级标题 2. undo 日志 四级标题 五级标题 六级标题 ...
MySQL(InnoDB剖析):40---事务之（事务的实现：undo log(回滚日志)）
董哥的黑板报
02-17 2608
事务隔离性可以使用前面介绍的锁来实现。原子性、一致性、持久性通过数据库的redo log和undo log来完成： redo log：称为重做日志。用来保证事务的原子性和持久性 undo log：用来保证事务的一致性 redo和undo的作用都可以视为一种恢复操作： redo恢复提交事务修改的页操作 undo回滚行记录到某个特定版本 因此两者记录的内容也不同： redo通......
说说MySQL中的Redo log Undo log都在干啥
dbtg45121的博客
03-15 1606
在数据库系统中，既有存放数据的文件，也有存放日志的文件。日志在内存中也是有缓存Log buffer，也有磁盘文件log file，本文主要描述存放日志的文件。 MySQL中的日志文件，有这么两类常常讨论到：undo日志与redo日志。 1 undo 1.1 undo是啥 undo日志用于存放数据修改被修改前的值，假设修改 tba 表中 id=2的行数据，把Name...
undo log日志长什么样
filling_l的博客
01-19 1362
      对于一个事务，如果有2条个增删改操作，如果目前已经执行了1个操作，修改了一些数据，还有1条逻辑没有执行，此时事务要回滚怎么办？Mysql中有一个回滚日志 undo log日志。       如果你在执行了一个insert语句，那么此时在Undo log日志中，对这个操作记录的回滚日志就必须有一个主键和一个对应的delete操作。       那么比如说你要执行的是delete操作，那么起码你要
深入分析MySQL事务日志-Undo Log日志
緑水長流*z
09-24 1万+
引入Undo Log Buffer是来提升Undo Log的性能的，比较操作内存要比操作磁盘快多了，但由此也引入了另外一个问题，那就是既然内存中记录了Undo Log的值，为什么还要在磁盘中也记录Undo Log的值呢？Tips：Undo Log主要保证事务的原子性，即通过记录修改前的状态，以提供回滚功能，其次Undo Log用于提供MVCC的快照读。，每个事务只会使用一个回滚段，当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
mysql undo log位置_MYSQL UNDO LOG物理格式
weixin_35272691的博客
01-19 805
InnoDB采用表空间 + 回滚段的方式来存储undo log。回滚段定义了UNDO文件的组织方式。在实现中，可以将UNDO LOG内容与INNODB中的其他数据存储在同一个文件，也可以将UNDO LOG单独存储，这取决于MYSQL initialize时的参数配置。文章中主要以独立UNDO文件来描述。UNDO TABLE SPACEUNDO TABLE SPACE指的是UNDO LOG 表空间，...
mysql undo log 查看_了解mysql的undo log
weixin_39850150的博客
01-19 2491
第一次了解mysql的时候，看到了undo log这个名词，却不知道undo log是干什么，为了能够继续看明白一些mysql的资料，不得不先弄明白undo log是什么? undo log的原理是什么？它与数据库的其它特性如何配何。这篇笔记只从原理上分析，不涉及具体的实现方法。undo log是什么?undo log是一种日志，日志中记录对于数据库的反向操作。如果把数据库的内容当做一种状态机，那...
MySQL三大日志——binlog、redoLog、undoLog详解
热门推荐
想着百万年薪努力的小赵
06-25 5万+
我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面： 1）、 因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！ 2）、 一个事务可能涉及修改多个数据页，并
MySQL的undo log 与MVCC
他叫阿来
11-27 2388
MVCC（Multi Version Concurrency Control）被称为多版本控制，是指在数据库中为了实现高并发的数据访问，对数据进行多版本处理，并通过版本链保证事务能看到自己应该看到的数据版本。 InnoDB 的**行数据有多个版本**，每个数据版本有自己的 row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读(快照读)，一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。
MySQL事务，从redo log、bin log、undo log说起...
Java Punk
07-20 1094
通过本讲，你将学到redo log、bin log、undo log日志系统的产生、释放过程，作用，以及与事务（ACID）的关系
MySQL进阶之路（十）——再探undo log原理
生命中有太多不确定
09-13 373
再探undo log原理 一、概述 ​ 在上一篇文章中我们详细介绍了redo log日志，介绍了redo log的作用、如何实现故障恢复、刷盘策略等，如果有忘记的小伙伴可以点这里快速复习一下。 ​ 本篇文章将详细介绍undo log的原理 二、undo log的作用 ​ 如果学习过前面几篇的文章，就已经知道了undo log的作用——用于事务的回滚。为什么事务需要回滚呢？这就不得不说到事务的ACID原则了，其中的A就是事务的原子性：当一个事物对数据库进行多次更改时，在提交时要么所有的改动都成功，要么在回滚事
MySQL 无缝迁移到达梦：前置方法与全面评估分析指南
最新发布
数记
12-20 752
MySQL迁移至达梦数据库（DM）的兼容性评估与迁移策略摘要 本文系统分析了从MySQL迁移到达梦数据库的关键步骤： 兼容性评估：检查表结构、SQL语法、存储过程等对象的兼容性，对比事务隔离、字符集等特性差异，使用达梦工具（如DTS、SQL Checker）辅助分析。 工作量分级：根据适配难度分为低（直接兼容）、中（语法调整）、高（代码重写）和阻断项（需业务改造），示例评估显示存储过程改造占比最高（40%）。 迁移实施：分阶段进行试点验证、灰度同步（dmdrs工具）和全量切换，结合达梦DTS工具自动转换，配
基于 MySQL Monitoring and Management 的性能保障实践
星哥玩云
12-17 955
摘要：本文探讨MySQL Monitoring and Management（MMM）工具在数据库性能保障中的实践应用。MMM作为官方推荐的轻量化监控方案，具有全栈指标覆盖、易部署和可视化告警等优势。重点分析了查询执行时间、连接数和缓存命中三大核心指标的监控逻辑与优化策略，并提供了从部署到日常监控的完整操作流程。通过电商平台案例展示了MMM在实际场景中的故障定位与性能优化价值，最后提出指标联动、动态阈值调整等优化建议，为构建高效的MySQL监控体系提供实用指南。
Canal深度解析：MySQL增量数据订阅与消费实战
qq_41262225的博客
12-18 814
Canal实战指南：MySQL增量数据同步利器 Canal是阿里巴巴开源的MySQL增量数据订阅组件，基于MySQL主从复制协议实现毫秒级数据同步。核心原理是伪装成MySQL从库，通过解析binlog获取数据变更，支持Row格式的binlog解析。典型应用场景包括缓存同步、实时数据分析、数据异构迁移等。 Canal架构包含三个核心组件：EventParser负责连接MySQL并解析binlog；EventSink进行数据过滤和路由；EventStore存储事件数据。部署时需配置MySQL开启binlog并设
MySQL 入门实验：环境搭建与基础操作全攻略
m0_71868960的博客
12-18 813
服务管理是基础：操作 MySQL 前务必确认服务已启动，否则会导致登录失败工具选择看场景：命令行适合快速执行简单命令，MySQL Workbench 可视化界面更适合复杂操作和结果查看SQL 语句规范：关键字建议大写（如 CREATE、SELECT），字段名和表名尽量见名知义，语句结尾可加英文分号主键约束很重要：创建表时设置主键（如学号）可保证数据唯一性，避免重复记录通过本次实验，不仅熟悉了 MySQL 的基本运行环境，更掌握了数据库操作的核心流程。
MySQL 处理重复数据
lsx202406的博客
12-15 346
处理重复数据是数据库维护中的一个重要环节。MySQL提供了多种方法来查找和删除重复数据，同时还有一些策略可以用来预防重复数据的产生。通过合理地使用这些工具和策略，可以确保数据库的整洁性和准确性。
MySQL 新手避坑指南：安装、区分、检查一步到位
m0_57021623的博客
12-17 1025
本文详细解释了在Linux系统中安装MySQL时常见的困惑，重点区分了MySQL客户端与服务端的不同。文章指出mysql-server是数据库服务端核心，包含mysqld进程和数据存储；而mysql仅是客户端工具。通过yum安装mysql-server mysql是最完整的安装方式，同时具备服务端和客户端功能。文中提供了多种验证安装状态的方法（如rpm查询、服务状态检查等），并澄清了常见误区（如混淆客户端与服务端）。最后强调生产环境中应避免混合安装方式，防止端口冲突等问题。全文以简洁语言帮助读者彻底理解My
mysql undo_log一直增长
07-23
<think>首先，用户的问题是关于MySQL中undo log持续增长的原因和解决方法。我需要基于提供的引用来构建回答。 关键引用内容： - 引用[1]：提到undo log文件无限膨胀，导致性能下降，History list length很大。原因包括复制延迟、长查询、事务锁和写入负载重导致无法清理垃圾事务。 - 引用[2]：类似内容，强调排查过程。 - 引用[3]：解释MySQL文件结构，包括共享表空间（ibdata1）和独立表空间（innodb_file_per_table）。 - 引用[4]：提到History list length太大引起的问题，如高IO使用率。 - 引用[5]：关于强制启动数据库的级别（innodb_force_recovery）。 用户意图：了解和解决undo log持续增长的问题。 我的回答需要： - 结构清晰，逐步解决问题。 - 使用中文。 - 遵循LaTeX格式：行内数学表达式用$...$，独立公式用$$...$$。 - 生成相关问题。 - 在引用的段落末尾添加引用标识，如[^1]。 回答结构： 1. **解释undo log是什么**：简要介绍undo log的作用。 2. **原因分析**：为什么undo log会持续增长。 3. **影响**：undo log膨胀带来的问题。 4. **解决方法**：如何解决和预防。 5. **相关问题生成**：在最后添加相关问题。 基于引用，原因包括： - 长事务或长查询：导致undo日志无法及时清理。 - 复制延迟：在从库中，未处理的事务保留在undo日志中。 - 高写入负载：失败的垃圾事务无法清理。 - History list length过大：表示未purge的事务数量高。 解决方法： - 监控和优化事务：避免长事务。 - 调整MySQL参数：如增加purge线程。 - 使用独立表空间：引用[3]提到innodb_file_per_table可以避免ibdata1无限增长。 - 强制恢复：在极端情况下使用innodb_force_recovery（引用[5]）。 确保回答真实可靠：基于引用信息，不要添加未经验证的内容。 最后，生成相关问题：基于主题，如监控、优化、参数设置等。 完整回答大纲： - 引言：undo log的定义和作用。 - 原因：详细列出原因。 - 影响：性能下降、IO等待高等。 - 解决方案： - 短期修复。 - 长期优化。 - 参数调整。 - 相关问题。</think>### MySQL undo log 持续增长的原因和解决方法 在 MySQL 数据库中，undo log 是一种用于支持事务回滚和并发控制的日志机制。它记录事务修改前的数据版本，确保事务的原子性和一致性[^3]。当 undo log 文件持续增长时，会导致磁盘空间占用增加、性能下降（如高 IO 等待和服务器负载上升），甚至影响主从复制延迟[^1][^2]。以下我将逐步分析原因并提供解决方法。分析基于 MySQL 的常见行为（如 InnoDB 存储引擎），并结合实际案例。 #### 1. **undo log 的作用和存储方式** - undo log 主要用于： - 事务回滚：如果事务失败，MySQL 使用 undo log 恢复数据到修改前的状态。 - 多版本并发控制 (MVCC)：提供读一致性视图，避免读写冲突。 - 在 MySQL 中，undo log 默认存储在共享表空间文件 `ibdata1` 中（如果未启用独立表空间）。启用 `innodb_file_per_table` 后，每个表的 undo log 会分离到独立文件（`.ibd`），但部分系统元数据仍保留在 `ibdata1`[^3]。当 undo log 无法及时清理时，文件会持续膨胀。 #### 2. **undo log 持续增长的原因** undo log 增长的根本原因是垃圾数据（已提交事务的 undo 记录）未被及时清除。具体原因包括： - **长事务或长查询**：如果一个事务运行时间过长（例如，超过数小时），其关联的 undo log 会被保留，直到事务结束。这会导致 `History list length` 值增大（表示未 purge 的事务数量），进而引发 undo log 膨胀[^1][^4]。例如： - 用户执行了一个未提交的大批量更新操作。 - 复杂查询（如全表扫描）占用了事务资源。 - **复制延迟**：在从库环境中，如果主从复制延迟高，从库无法及时应用事务，导致 undo log 累积。引用[^1]指出：“复制延迟会导致从库的 History list length 增加，因为未处理的事务会保留在undo日志中”。 - **高写入负载和失败事务**：高并发写入场景下，事务失败或回滚频繁产生垃圾 undo 记录。如果 purge 线程（负责清理 undo log）无法跟上负载，这些记录会堆积[^1][^2]。 - **InnoDB 参数配置不当**： - `innodb_purge_threads` 设置过低（默认 4），无法高效清理。 - `innodb_max_purge_lag` 参数未调整，导致 purge 延迟。 - **其他因素**：表锁或行锁冲突延长事务持有时间，或者磁盘 IO 瓶颈延缓 purge 过程[^4]。 数学上，undo log 增长可建模为： $$ \text{Undo Size} \propto \int (\text{Transaction Rate} \times \text{Transaction Duration}) \, dt $$ 其中，事务持续时间和速率越高，undo log 膨胀越快。 #### 3. **undo log 膨胀的影响** - **性能下降**：undo log 文件增大导致磁盘 IO 等待增加（`iostat` 显示使用率超 90%），服务器负载上升，即使 TPS（每秒事务数）不高[^1][^4]。 - **空间耗尽**：`ibdata1` 文件无限增长，可能占满磁盘。 - **主从延迟**：在从库中，undo log 膨胀会加剧复制延迟。 - **系统不稳定**：严重时可能触发 InnoDB 错误或崩溃。 #### 4. **解决方法** 解决 undo log 增长需从监控、优化事务和调整参数入手。以下是逐步方案： **步骤 1: 诊断问题** - 检查 `History list length`： ```sql SHOW ENGINE INNODB STATUS; ``` 在输出中查找 `TRANSACTIONS` 部分，如果 `History list length` 超过 1000，表示问题严重（正常值应小于 100）[^1][^2]。 - 监控 undo log 大小： ```bash ls -lh /var/lib/mysql/ibdata1 # 共享表空间路径 ``` 如果文件持续增大，结合 `iostat` 确认 IO 压力。 **步骤 2: 短期修复** - **终止长事务**： - 使用 `SHOW FULL PROCESSLIST` 找出并 kill 长时间运行的事务。 - 示例：`KILL [process_id];`。 - **强制清理**： - 如果数据库已不稳定，使用 `innodb_force_recovery` 参数强制启动（从级别 1 开始测试）[^5]： ```ini [mysqld] innodb_force_recovery = 1 # 忽略损坏页，dump 数据后重建 ``` 级别 1-6 逐步增加强度，但高级别可能损坏数据，仅用于紧急恢复。 - **重启 MySQL**：临时释放资源，但非根治方案。 **步骤 3: 长期优化** - **优化事务**： - 避免长事务：将大事务拆分为小批量操作（例如，分页更新）。 - 减少锁竞争：使用索引优化查询，缩短事务持有时间。 - **调整 InnoDB 参数**： - 增加 purge 线程：`innodb_purge_threads = 8`（根据 CPU 核数调整）。 - 设置 purge 延迟阈值：`innodb_max_purge_lag = 100000`（控制 History list length 上限）。 - 启用独立表空间：在 `my.cnf` 中添加： ```ini innodb_file_per_table = ON ``` 这能隔离 undo log，避免 `ibdata1` 无限增长[^3]。但需注意：对已存在的表，需重建（`ALTER TABLE ... ENGINE=InnoDB`）。 - **监控和维护**： - 定期检查 `History list length` 和 undo log 大小。 - 使用工具如 `pt-kill` 自动终止长查询。 - **处理复制延迟**：优化从库配置（如增加 `innodb_read_io_threads`），并确保网络稳定。 **步骤 4: 预防措施** - 在开发阶段：避免设计长事务；测试高负载场景。 - 参数调优：根据负载动态调整 `innodb_purge_batch_size`。 - 升级 MySQL：新版本（如 MySQL 8.0）对 undo log 管理更高效[^3]。 如果问题持续，建议结合 AWR 报告或 Percona Toolkit 深入分析。实践中，多数案例通过优化事务和参数解决[^1][^2]。 #### 相关问题 1. 如何监控 MySQL 的 `History list length` 并设置告警？ 2. 在复制环境中，如何减少主从延迟导致的 undo log 膨胀？ 3. 独立表空间 (`innodb_file_per_table`) 对 MySQL 性能有哪些影响？ 4. 使用 `innodb_force_recovery` 时，如何最小化数据损坏风险？ [^1]: 复制延迟会导致从库的 History list length 增加，因为未处理的事务会保留在undo日志中，此时 undo log 就会膨胀。长查询和事务锁会导致 History list length 增加，因为相关的undo日志无法被及时清理，此时 undo log 就会膨胀。Mysql 写入负载太重存在失败的垃圾事务，并且无法清理掉。 [^2]: 在 Mysql 数据目录中发现有个 undo 文件非常大，并且持续增长，并且 History list length 非常大。 [^3]: MySQL里面的文件蛮有意思，之前大体有两个参数来做基本的控制。一个是innodb_data_file_path就是一个共享表空间，数据都往这一个文件里放，也就是ibdata1,这个文件其实角色是有重复的，undo，数据都会放在一起。ibdata1会持续增长，无法收缩。另外一个参数是innodb_file_per_table，这样一来，就成了独立表空间。 [^4]: 主库的iostat的使用率一直在90%以上，Mysqldata所在目录的大小一直没变；主库的ib_logfile20分钟切换一次(主库上面的innodblog写得还是比较频繁)，而从库的ib_logfile4小时切换一次。 [^5]: innodb_force_recovery 可以设置为 1-6，大的值包含前面所有小于它的值的影响。1=(SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的 corrupt 页。尽管检测到了损坏的 page 仍强制服务运行。一般设置为该值即可，然后 dump 出库表进行重建。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值