1. Undo Log 概述在 MySQL 的 InnoDB 存储引擎体系中Undo Log 是最容易被忽视、却最容易在线上引发严重故障的组件之一。很多数据量大、写入并发高的系统最终不是倒在了磁盘容量上而是倒在了几十 GB 甚至上百 GB 的 undo 表空间上。理解 Undo Log 的工作原理、掌握其参数配置与日常运维方法是每一位 MySQL DBA 和资深后端开发者的必修课。Undo Log 是 InnoDB 为支持事务回滚和多版本并发控制而维护的一种逻辑日志。它与 Redo Log 有本质区别Redo Log 是物理日志记录的是「数据页上的某个位置发生了什么变化」用于崩溃恢复而 Undo Log 是逻辑日志记录的是「某条数据被修改前的旧值」用于事务回滚和 MVCC 读取。简单来说Redo Log 负责「重做」Undo Log 负责「撤销」。当一条 SQL 语句执行 UPDATE、DELETE 或 INSERT 操作时InnoDB 会在修改数据页之前先把修改前的数据镜像写入 Undo Log。这样设计的目的十分明确如果事务最终需要回滚数据库可以依据 Undo Log 把数据恢复成修改前的状态如果事务提交后其它并发事务还需要读取该行的旧版本Undo Log 又能支撑 MVCC 快照读的实现。因此Undo Log 并非只在回滚时有用它是 InnoDB MVCC 机制的底层支撑。只要数据库存在并发事务和一致性读需求Undo Log 就必须长期保留直到没有任何事务再需要访问这些旧版本数据为止。这一特性也直接造成了 Undo Log 常见的「只增不减、容易膨胀」的问题。2. Undo Log 的核心作用要真正理解 Undo Log 的配置与优化首先要搞清楚它到底承担了哪些职责。概括起来Undo Log 主要有四大作用事务回滚、MVCC 多版本并发控制、崩溃恢复阶段的未提交事务回滚以及 purge 清理的数据来源。2.1 事务回滚事务回滚是 Undo Log 最直观的作用。当用户显式执行 ROLLBACK 语句或者事务因为异常被强制回滚时InnoDB 需要把该事务修改过的数据恢复到修改之前的状态。这个「修改之前的状态」就记录在 Undo Log 中。例如下面的场景START TRANSACTION; UPDATE account SET balance balance - 100 WHERE user_id 1001; UPDATE account SET balance balance 100 WHERE user_id 1002; ROLLBACK;如果第二条 UPDATE 执行失败或者用户回滚InnoDB 会根据第一条 UPDATE 产生的 Undo Log把 user_id 为 1001 的账户余额恢复到扣减 100 元之前的值。整个回滚过程依赖的就是事务执行期间写入的 Undo 记录。2.2 MVCC 多版本并发控制MVCC 是 InnoDB 实现高并发读的核心机制。它允许普通的 SELECT 语句在不加锁、不阻塞写操作的情况下读取到事务开始时的一致性快照。实现这一能力的关键就是 Undo Log 中保存的行历史版本。InnoDB 的聚簇索引记录中每一行都包含两个隐藏列DB_TRX_ID 和 DB_ROLL_PTR。DB_TRX_ID 表示最后一次修改该行的事务 IDDB_ROLL_PTR 则是指向该行上一个版本在 Undo Log 中位置的指针。当一个一致性读事务需要读取某行数据时如果发现该行的最新版本是在本事务开始之后才提交的就会顺着 DB_ROLL_PTR 指针在 Undo Log 中查找符合快照要求的旧版本。这意味着只要还有事务可能读取某个旧版本对应的 Undo Log 就不能被清理。这也解释了为什么长事务会导致 Undo Log 急剧膨胀——因为长事务持续持有旧的一致性视图使得大量 Undo 记录无法被 purge。2.3 崩溃恢复当数据库意外宕机后重启InnoDB 会利用 Redo Log 把已提交事务的修改重做到数据页上。但此时可能存在一部分未提交事务的修改也被重做了。为了把这部分未提交事务的修改撤销掉InnoDB 需要扫描 Undo Log找出所有未提交事务并执行回滚操作。这个阶段叫做 crash recovery 中的 rollback of uncommitted transactions。因此Undo Log 不仅在正常运行中承担回滚职责在崩溃恢复阶段同样是保证数据一致性的关键一环。如果 Undo 表空间损坏或者空间不足崩溃恢复过程可能无法顺利完成甚至导致数据库无法正常启动。2.4 支撑 purge 操作当一条 DELETE 语句执行时InnoDB 并不会立刻把该行数据从磁盘上物理删除而是先在该行上打一个删除标记真正的物理删除由后台的 purge 线程完成。purge 线程依据的就是 Undo Log 中的删除记录。同理UPDATE 操作本质上也是「标记旧版本 插入新版本」的过程旧版本的物理清理同样依赖 purge。一旦 purge 操作完成对应的 Undo 记录就不再被任何事务需要可以被释放并供后续重用。因此purge 的效率直接决定了 Undo 表空间能否得到有效回收。3. Undo Log 的存储结构理解 Undo Log 的存储结构是进行参数优化和空间诊断的基础。不同 MySQL 版本的存储形式差异较大下面分别介绍传统回滚段和新版独立 Undo 表空间两种体系。3.1 回滚段与 Undo 段在传统架构中InnoDB 通过回滚段来组织 Undo 记录。一个回滚段可以管理一组 undo slot每个 undo slot 对应一个 undo 段。undo 段由若干 undo 页面组成这些页面按照链表的方式组织形成一个 undo 日志的链式结构。每个事务在执行写操作时需要从回滚段中分配一个 undo 段。事务修改的数据越多undo 段中写入的 undo 页面就越多。如果写入的量超过了当前 undo 段所能容纳的范围InnoDB 会继续申请新的页面并追加到链表尾部。在 MySQL 5.6 及更早版本中回滚段存储在一个共享的表空间内。到了 MySQL 5.7 和 8.0InnoDB 支持使用独立的 undo 表空间将回滚段从系统表空间中分离出来从而支持更加灵活的 truncate 和空间管理。3.2 独立 Undo 表空间MySQL 5.7 开始支持独立的 undo 表空间默认情况下 undo 日志存放在独立的 undo 表空间文件中。MySQL 8.0 则彻底将 undo 日志从系统表空间中移除默认创建两个独立的 undo 表空间文件undo_001 和 undo_002。独立 undo 表空间的好处十分明显便于收缩支持在线 truncate可以把膨胀的 undo 表空间物理文件收缩回初始大小。便于管理undo 文件可以被移动到指定的目录便于分散 IO 压力。故障隔离undo 表空间的问题不会直接影响系统表空间中的其它数据结构。在 MySQL 8.0 中还可以通过 CREATE UNDO TABLESPACE 语句动态创建额外的 undo 表空间并且可以通过 ALTER UNDO TABLESPACE 语句将其设置为活动或非活动状态配合 truncate 进行空间收缩。3.3 Undo 记录的两种类型InnoDB 的 undo 记录根据操作类型可以分为 INSERT undo 和 UPDATE undo 两大类。INSERT undo 对应 INSERT 操作的撤销信息这部分 info 通常只在事务提交后即可删除因为新插入的行如果没有提交其它事务看不到不存在 MVCC 需求。而 UPDATE undo 对应 UPDATE 和 DELETE 操作的撤销信息这部分需要根据事务隔离级别和并发读需求保留更长时间。由于 UPDATE undo 与 MVCC 直接相关它才是造成 undo 表空间膨胀的罪魁祸首。因此在诊断 undo 空间问题时重点要关注是否存在大量未 purge 的 UPDATE undo 记录。4. Undo 表空间体系与文件分布在深入参数配置之前有必要先厘清不同版本下 undo 表空间文件的分布情况和命名规律这样在排查问题时才能迅速定位文件位置。4.1 MySQL 5.6 及之前在 MySQL 5.6 及更早版本中undo 日志存储于共享的 ibdata 系统表空间中。这种设计存在一个非常头疼的问题ibdata 文件只会增大不会收缩。即使事务已经提交、undo 记录已经被 purge这些空间也只能被后续的 undo 记录重用却无法从物理上释放。很多老系统在运行数年后ibdata1 文件从初始的 10 MB 膨胀到数十 GB最终只能通过重建实例来解决。4.2 MySQL 5.7MySQL 5.7 自 5.7.5 版本开始支持独立 undo 表空间但默认配置在部分发行版中仍然使用系统表空间。如果希望使用独立 undo 表空间需要在初始化实例时显式指定 innodb_undo_tablespaces 参数。需要注意的是MySQL 5.7 中该参数只有在初始化时才能生效实例创建后无法修改。MySQL 5.7 的独立 undo 表空间文件默认位于数据目录下命名为 undo001、undo002 等。此外MySQL 5.7 还支持设置 innodb_undo_log_truncate 参数当 undo 表空间超过阈值时自动执行 truncate 收缩。4.3 MySQL 8.0MySQL 8.0 对 undo 表空间进行了全面重构默认创建两个独立 undo 表空间 undo_001 和 undo_002不再使用系统表空间存放 undo。支持在线动态创建和删除 undo 表空间。支持在多个 undo 表空间之间动态切换活动状态。支持将 undo 表空间设置为 inactive 后进行 truncate整个过程在线完成。MySQL 8.0 的 undo 表空间命名以 undo_ 开头后面跟数字序号。用户创建的自定义 undo 表空间需要以 .ibu 为扩展名。例如CREATE UNDO TABLESPACE undo_003 ADD DATAFILE undo_003.ibu;这一机制让 DBA 可以像管理普通表空间一样管理 undo 表空间极大地增强了运维灵活性。5. 核心配置参数详解本节是整篇指南的重中之重。我们将逐一剖析与 undo log 相关的核心参数包括参数含义、默认值、适用场景、调优建议以及不同版本之间的差异。5.1 innodb_undo_directory该参数用于指定 undo 表空间文件的存放目录。默认情况下undo 表空间文件存放在数据目录中。如果业务写入量较大建议将 undo 表空间放到独立的、高性能的存储设备上以降低与数据文件和 redo log 之间的 IO 争用。配置示例[mysqld] innodb_undo_directory /data/mysql_undo/需要注意的是该参数在 MySQL 5.7 中只有在初始化实例时指定才有效在 MySQL 8.0 中创建 undo 表空间时也可以通过 ADD DATAFILE 子句指定绝对路径但不建议将文件路径直接放在 innodb_undo_directory 之外以免造成管理混乱。5.2 innodb_undo_tablespaces该参数用于指定独立 undo 表空间的数量。在 MySQL 5.7 中它控制初始化时创建的 undo 表空间文件数量在 MySQL 8.0 中该参数已经被废弃改为使用 CREATE UNDO TABLESPACE 动态管理。在 MySQL 5.7 中默认值为 0即不使用独立 undo 表空间而是沿用系统表空间。如果希望启用独立 undo 表空间需要在初始化实例前设置[mysqld] innodb_undo_tablespaces 3在 MySQL 8.0 中官方推荐至少维护两个活动状态的 undo 表空间以便轮换执行 truncate。如果存在单个表空间长期无法切换 inactive 的情况可能需要创建更多的 undo 表空间进行轮换。5.3 innodb_undo_log_truncate该参数控制是否启用 undo 表空间的自动 truncate 收缩功能。默认值为 ONMySQL 8.0或 OFFMySQL 5.7 默认关闭需要手动开启。当启用该功能后InnoDB 会定期检查 undo 表空间的大小如果某个 undo 表空间超过阈值就会尝试将其标记为 inactive并执行 truncate 操作把物理文件收缩到初始大小。配置示例[mysqld] innodb_undo_log_truncate ON启用自动 truncate 前需要满足几个前提实例中至少存在两个 undo 表空间innodb_undo_tablespaces 大于等于 2MySQL 5.7undo 表空间支持在线切换 inactive。否则 truncate 无法执行。5.4 innodb_max_undo_log_size该参数定义了单个 undo 表空间触发自动 truncate 的大小阈值。默认值为 1 GB。当某个 undo 表空间的大小超过该阈值并且该表空间可以被标记为 inactive 时InnoDB 就会执行 truncate。参数支持的单位有 KB、MB、GB。配置示例[mysqld] innodb_max_undo_log_size 4G需要注意的是innodb_max_undo_log_size 只是一个触发阈值的软限制undo 表空间的实际大小可能暂时超过该值。此外该参数过小时会导致 truncate 频繁触发带来额外的 IO 开销和性能抖动过大则会失去空间控制的意义。通常建议根据业务的写入峰值和单次大事务规模来综合设定常见经验值为 1 GB 到 8 GB 之间。5.5 innodb_purge_threads该参数用于指定后台 purge 线程的数量。purge 线程负责清理被标记删除的记录并释放不再被任何事务需要的 undo 记录。默认值为 4MySQL 8.0。如果业务环境中 UPDATE 和 DELETE 操作非常频繁purge 速度赶不上产生速度就会造成 undo 空间持续增长。当数据库出现以下现象时可以考虑增加 purge 线程数量History List Length 持续处于高位且没有下降趋势。undo 表空间不断增大即便没有大的长事务。SHOW ENGINE INNODB STATUS 中显示 purge 累积严重滞后。配置示例[mysqld] innodb_purge_threads 8该参数的上限为 32但并不是越大越好。purge 线程过多会增大对数据页和 undo 页的并发访问压力甚至与业务读写争抢资源。一般建议从 4 开始逐步调高结合实际监控数据确定最优值。5.6 innodb_purge_batch_size该参数定义了每个 purge 批次最多能处理和提交的 undo 记录数量。默认值为 300。适当增大该值可以提高每次 purge 的处理效率减少 purge 提交的频率从而提升历史版本清理的速度。但如果设置过大可能导致 purge 操作单次占用过多资源引起业务响应时间的毛刺。配置示例[mysqld] innodb_purge_batch_size 1000建议在写入压力大、历史版本堆积严重时适度调大该参数同时密切观察系统负载和业务延迟避免调优过度。5.7 innodb_rollback_segments该参数用于指定每个 undo 表空间中的回滚段数量。默认值为 128。回滚段数量决定了数据库中同时能够进行的并发写入事务的上限。每个回滚段可以包含 1024 个 undo slot因此默认配置能够支撑相当可观的并发事务数。在 MySQL 8.0 中用户无法直接修改该参数的默认值 128。这个参数更多是用于理解并发事务与 undo 资源的对应关系。正常情况下无需调整但在极高高并发的写入场景下如果怀疑并发事务数已经逼近回滚段上限可以通过查看视图来验证。5.8 innodb_undo_log_encrypt该参数用于控制是否对 undo 表空间进行加密。从安全合规的角度看undo 日志中同样保存着业务数据的旧版本信息如果磁盘泄露undo 文件同样可能造成敏感数据泄露。因此在启用了>[mysqld] innodb_undo_log_encrypt ON该参数支持动态修改。修改后新创建的 undo 表空间会自动启用加密已存在的 undo 表空间需要在执行 truncate 时才能完成加密方式的转换。5.9 参数汇总表参数名默认值作用简述MySQL 8.0 建议值innodb_undo_directory数据目录undo 文件存放目录独立高速存储目录innodb_undo_tablespaces8.0 已废弃独立 undo 表空间数量使用动态管理innodb_undo_log_truncateON8.0是否自动 truncateONinnodb_max_undo_log_size1 GBtruncate 触发阈值1 GB 到 8 GBinnodb_purge_threads4purge 线程数4 到 16innodb_purge_batch_size300每批 purge 记录数300 到 2000innodb_rollback_segments128每表空间回滚段数保持默认innodb_undo_log_encryptOFFundo 文件加密按安全要求开启6. Purge 机制深度解析Purge 机制是理解 undo 空间管理的核心。很多 undo 空间持续膨胀的问题本质上都是 purge 不及时造成的。本节从原理到实践完整解析 purge 的工作流程和优化方法。6.1 purge 的触发时机当一个事务提交后它的 undo 记录并不会立即被删除因为可能会有更早启动的读事务仍然需要读取这些旧版本数据。InnoDB 使用 history list 来维护所有「已经提交、但尚未清理」的 undo 记录。当 purge 线程运行时它会根据系统中所有活跃读事务的最老快照确定哪些 undo 记录已经不可能再被访问然后将其清理。purge 的触发时机主要包括后台 purge 线程周期性地唤醒并执行清理。当前系统中需要分配新的 undo 页时触发一定量的 purge 以释放空间。InnoDB 内部根据 history list 长度决定是否加大 purge 强度。6.2 History List Length 的意义History List Length 是诊断 undo 问题最重要的指标之一。它表示当前系统中尚未被 purge 处理的 undo 记录数量。该值可以通过以下命令查看SHOW ENGINE INNODB STATUS\G在输出结果中查找 History list length 字段------------ TRANSACTIONS ------------ Trx id counter 42356789 Purge done for trxs n:o 42356100 undo n:o 0 state: running but idle History list length 2893正常情况下History List Length 会在事务提交后逐渐回落。如果该值长期维持在高位或者持续单调递增说明 purge 已经严重滞后需要立即排查原因。常见原因包括长事务阻塞了 purge 的推进、purge 线程资源不足、大事务一次性产生了海量 undo 记录等。6.3 purge 滞后的排查思路当发现 History List Length 过高时可以按照以下顺序排查-- 1. 查找当前最老的事务 SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.innodb_trx ORDER BY trx_started ASC LIMIT 20;这条 SQL 可以找出启动时间最早的事务。如果一个事务启动了数小时乃至数天它就会一直持有最老的快照导致 purge 无法清理其启动之后产生的所有 undo 记录。-- 2. 查找长时间未提交的事务 SELECT trx_id, trx_started, trx_mysql_thread_id, trx_state, NOW() - trx_started AS duration, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING ORDER BY trx_started ASC;对于确认已经僵死的长事务应尽快与业务方确认后执行 kill 或者回滚。-- 3. 查看当前 purge 是否处于运行状态 SHOW GLOBAL STATUS LIKE Innodb_purge%;如果相关状态值长时间没有变化可能意味着 purge 线程卡住需要进一步检查是否存在资源竞争问题。7. Undo 表空间监控与诊断完善的监控体系是避免 undo 空间故障的第一道防线。本节介绍如何通过系统视图、状态变量和操作系统命令对 undo 表空间进行持续监控和快速诊断。7.1 查看 undo 表空间基本情况在 MySQL 8.0 中可以通过 information_schema.INNODB_TABLESPACES 视图查看所有 undo 表空间的信息SELECT SPACE, NAME, FILE_SIZE, ALLOCATED_SIZE, STATE FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE undo%;该查询可以直观地看到每个 undo 表空间当前的物理文件大小、已分配空间以及活动状态。重点关注 FILE_SIZE 是否接近或超过磁盘剩余空间以及 STATE 是否为 active。7.2 查看 undo 相关状态变量以下状态变量与 undo 和 purge 运行状态密切相关SHOW GLOBAL STATUS LIKE Innodb_undo%;常见字段说明Innodb_undo_tablespaces_totalundo 表空间总数。Innodb_undo_tablespaces_implicit初始化时隐式创建的 undo 表空间数量。Innodb_undo_tablespaces_explicit用户显式创建的 undo 表空间数量。Innodb_undo_tablespaces_active当前处于 active 状态的 undo 表空间数量。7.3 监控 History List LengthHistory List Length 是判断 purge 健康度的核心指标。建议在监控系统中采集该指标并设定告警阈值。可以通过下面的查询定期获取SELECT name, count FROM information_schema.innodb_metrics WHERE name IN (trx_rseg_history_len, trx_rseg_current_size);其中 trx_rseg_history_len 对应 History List Length。当该值超过一定阈值例如 10 万并持续上升时应立即告警。7.4 监控 purge 处理效率除了 History List Length 的绝对值外还可以监控 purge 的推进速度SHOW GLOBAL STATUS LIKE Innodb_purge_trx_id_del; SHOW GLOBAL STATUS LIKE Innodb_purge_trx_id_age;其中 Innodb_purge_trx_id_age 表示当前最新事务 ID 与 purge 已完成事务 ID 之间的差值反映 purge 滞后的程度。如果该值不断增大说明 purge 速度跟不上事务产生的速度。8. Undo 表空间收缩实战当 undo 表空间已经膨胀到很大时手动或自动执行 truncate 是回收空间的唯一有效手段。本节详细介绍 MySQL 8.0 中 undo 表空间收缩的完整流程和注意事项。8.1 自动 truncate 的前提条件自动 truncate 需要同时满足以下条件innodb_undo_log_truncate 设置为 ON。存在至少两个活动状态的 undo 表空间MySQL 5.7或至少两个可轮换的表空间MySQL 8.0。目标 undo 表空间的大小超过 innodb_max_undo_log_size。目标 undo 表空间可以被安全地标记为 inactive即其中没有未提交事务和未被 purge 的旧版本数据。8.2 MySQL 8.0 手动 truncate 流程当自动 truncate 未触发或者希望立即收缩某个已经膨胀的 undo 表空间时可以手动执行以下流程-- 1. 查看当前所有 undo 表空间状态 SELECT SPACE, NAME, FILE_SIZE, STATE FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE undo%;-- 2. 将目标 undo 表空间设置为 inactive ALTER UNDO TABLESPACE undo_001 SET INACTIVE;需要注意该命令只有在目标 undo 表空间中没有活跃事务时才能成功。如果表空间中仍有事务未提交或旧版本数据未被 purge命令会等待或失败。-- 3. 在操作系统层面确认文件大小 -- 在数据目录下执行以 Linux 为例 ls -lh undo_001.ibu-- 4. 重新激活 undo 表空间 ALTER UNDO TABLESPACE undo_001 SET ACTIVE;在 inactive 状态下InnoDB 会自动对该 undo 表空间执行 truncate 操作。再次查看到文件大小时会发现已经收缩到初始大小。最后将其重新置为 active 即可。8.3 无法 truncate 时的排查步骤如果执行 SET INACTIVE 一直无法成功通常是有事务或旧版本数据仍然占用该 undo 表空间。此时需要-- 查找正在使用该 undo 表空间的活跃事务 SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING ORDER BY trx_started ASC;将查出来的长事务处理掉后再尝试执行 SET INACTIVE。如果还是失败可以检查是否有未结束的备份会话、复制线程或 XA 事务占用 undo 资源。9. 大事务与长事务的排查与治理大事务和长事务是 undo 空间膨胀的最主要原因。本节重点介绍如何发现、定位和处理这些问题从源头减少 undo 空间的异常消耗。9.1 大事务对 undo 的影响一个事务修改的行数越多产生的 undo 记录就越多undo 表空间就会相应增大。如果单个事务一次性修改了上亿行数据它产生的 undo 记录甚至可能达到数十 GB。更麻烦的是这个事务在提交之前它的所有 undo 记录都不能被 purgeundo 表空间会被持续占用。9.2 发现大事务的方法-- 列出当前所有活跃事务并查看它们修改的行数 SELECT trx_id, trx_started, trx_rows_modified, trx_state, trx_query FROM information_schema.innodb_trx WHERE trx_rows_modified 0 ORDER BY trx_rows_modified DESC LIMIT 20;trx_rows_modified 字段表示事务到目前为止修改的行数。该值过大的事务就是需要重点关注的大事务。建议在监控系统中对此字段进行持续采集一旦发现超过阈值例如 10 万行立即告警。9.3 长事务的识别与处理长事务的识别除了通过 trx_started 字段判断事务运行时长外还要特别注意那些启动时间早、但当前处于空闲状态的事务。这类事务可能来自应用层开启了事务却没有及时提交或回滚。-- 查找运行时间超过 60 秒的事务 SELECT trx_id, trx_mysql_thread_id, trx_started, NOW() - trx_started AS duration, trx_state, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING AND NOW() - trx_started 60 ORDER BY trx_started ASC;对于确认是应用层泄漏的事务需要定位到对应的 MySQL 线程 ID 并谨慎处理-- 查看该事务对应的会话连接信息 SELECT * FROM information_schema.processlist WHERE ID trx_mysql_thread_id;确认连接来源后协同业务方执行 kill 或回滚。不要贸然 kill 正在执行重要业务操作的事务以免造成业务数据不一致。9.4 从代码层治理大事务彻底治理大事务问题最终还是要在应用代码层做文章。常见治理思路包括将大批量 UPDATE 或 DELETE 操作拆分为多个小批次执行每批次提交一次事务。在批量任务执行间隙主动释放事务避免长时间持有。将非必要的 SELECT 移出事务范围减少事务持续时间。对热点行更新进行限流和削峰避免同一时间堆积大量并发修改。例如将一次性删除 1000 万行的操作拆分为每批 1 万行-- 分批删除示例存储过程片段 DELIMITER // CREATE PROCEDURE purge_big_table() BEGIN DECLARE affected_rows INT DEFAULT 1; WHILE affected_rows 0 DO START TRANSACTION; DELETE FROM big_table WHERE create_time 2025-01-01 LIMIT 10000; SET affected_rows ROW_COUNT(); COMMIT; DO SLEEP(0.5); END WHILE; END // DELIMITER ;这种分批处理方式可以显著降低单事务的 undo 压力同时也降低了对主从复制的延迟影响。10. Undo 空间相关的典型故障与处理线上系统一旦遇到 undo 空间问题往往表现为磁盘告警、业务写入变慢甚至数据库直接不可用。本节总结几类典型故障的排查和处理全过程。10.1 磁盘空间被 undo 占满故障现象监控告警显示磁盘使用率接近 100%排查后发现 undo 表空间文件异常巨大。可能是某个大事务正在持续执行也可能是长事务阻塞了 purge。处理步骤立即确认是否存在正在执行的大事务。如果有先评估能否等待其完成若事务已经失控与业务方沟通后执行 kill。确认是否存在长时间未提交的事务将其清理掉。检查 purge 线程是否在正常工作如果 History List Length 巨大适当调大 purge 相关参数。临时扩大磁盘空间或者将 undo 文件迁移到空间充足的目录避免数据库因磁盘满而挂起。待 undo 膨胀问题缓解后执行 truncate 收缩 undo 表空间。10.2 数据库启动时 undo 表空间报错故障现象实例重启时错误日志出现 undo 表空间相关的报错例如文件缺失、损坏或空间不足导致实例无法启动。处理思路检查错误日志中的具体报错信息确认是哪个 undo 表空间出现问题。确认该 undo 表空间文件是否存在于指定目录权限是否正确。检查磁盘剩余空间是否足够存放 undo 临时文件。如果是个别 undo 表空间损坏可以尝试将其删除后重新创建但需谨慎评估数据一致性风险建议先咨询官方支持或资深 DBA。切勿在没有备份的情况下随意删除 undo 表空间文件否则可能导致数据不一致甚至实例无法启动。10.3 purge 卡住导致 undo 膨胀故障现象事务提交正常但 undo 表空间持续增大SHOW ENGINE INNODB STATUS 中 History list length 持续攀升purge 相关状态不再变化。排查要点确认 purge 线程是否被阻塞。可能的原因是某个锁等待或资源竞争。检查 innodb_purge_threads 参数是否过低尝试适度调高。观察系统 CPU、IO 负载确认 purge 是否因为资源不足而无法推进。检查是否存在极老的事务快照阻止了 purge 清理后续 undo 记录。通常只要清除了最老的长事务History List Length 就会迅速回落undo 表空间也会在后续的 truncate 中收缩。11. 版本演进与差异对照了解不同 MySQL 版本在 undo 管理上的差异有助于在升级或迁移过程中避免踩坑。下表总结了 MySQL 5.6、5.7 和 8.0 三个主要版本的关键差异。特性MySQL 5.6MySQL 5.7MySQL 8.0undo 存放位置系统表空间 ibdata支持独立表空间独立表空间undo 表空间管理不可单独管理初始化时固定数量动态创建与删除在线 truncate不支持支持自动 truncate支持自动与手动轮换 truncateundo 空间收缩需要重建实例自动 truncate手动 SET INACTIVE 后 truncate加密支持不支持支持全面支持默认 undo 文件无独立文件undo001 等undo_001、undo_002从 5.6 升级到 8.0 时最明显的变化就是 undo 表空间的结构和管理方式。升级前需要确认目标版本的 undo 表空间数量和配置避免升级后因为配置不兼容导致实例无法启动。12. Undo Log 运维操作手册本节提供一份可随时查阅的操作手册覆盖日常运维中最常用的 undo 相关操作。12.1 查看 undo 表空间信息-- 查看所有 undo 表空间 SELECT SPACE, NAME, FILE_SIZE, ALLOCATED_SIZE, STATE FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE undo% ORDER BY SPACE;12.2 动态创建 undo 表空间-- 创建新的 undo 表空间 CREATE UNDO TABLESPACE undo_003 ADD DATAFILE undo_003.ibu;创建完成后新表空间默认为 active 状态InnoDB 会自动将新事务分布到其中。12.3 删除 undo 表空间-- 先将其设置为 inactive ALTER UNDO TABLESPACE undo_003 SET INACTIVE; -- 再删除 DROP UNDO TABLESPACE undo_003;注意undo 表空间只有在 inactive 状态下才能被删除。如果其中存在活跃事务或未被 purge 的旧版本数据SET INACTIVE 会等待。12.4 手动收缩 undo 表空间-- 将目标表空间设为 inactive触发自动 truncate ALTER UNDO TABLESPACE undo_001 SET INACTIVE; -- 观察文件大小已收缩后重新激活 ALTER UNDO TABLESPACE undo_001 SET ACTIVE;12.5 修改 undo 相关参数-- 动态开启自动 truncate SET GLOBAL innodb_undo_log_truncate ON; -- 动态调整最大 undo 大小阈值8.0 支持动态修改 SET GLOBAL innodb_max_undo_log_size 4294967296; -- 动态调整 purge 线程数 SET GLOBAL innodb_purge_threads 8;需要注意的是部分参数修改后只对新生成的 undo 记录生效对已有 undo 数据不会立即产生影响配置变更应结合监控数据逐步验证效果。12.6 批量查询活跃事务-- 查询当前所有未提交事务 SELECT trx_id, trx_state, trx_started, trx_rows_modified, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING ORDER BY trx_started ASC;建议将这类查询固化到监控脚本中定期执行并记录结果便于问题发生后回溯分析。13. 最佳实践与优化建议结合前文的分析本节总结出一套在生产环境中经过验证的 undo log 运维最佳实践供读者直接参考落地。13.1 存储规划为 undo 表空间单独规划存储目录与数据目录和 binlog 分开减少 IO 争用。优先使用 SSD 或高性能 NVMe 盘存放 undo 文件因为 undo 的读写具有随机性。预留充足的磁盘空间按照日常写入量的 2 到 3 倍评估 undo 峰值占用。13.2 参数配置基线对于大多数中等规模业务可以采用以下参数基线[mysqld] innodb_undo_log_truncate ON innodb_max_undo_log_size 4G innodb_purge_threads 8 innodb_purge_batch_size 600对于写入特别频繁的系统可以适当调高 purge 线程数和批量大小但要注意避免过度调优导致资源争抢。13.3 日常巡检清单每日检查 undo 表空间文件大小及磁盘剩余空间。每日检查 History List Length 的峰值和趋势。每日检查是否存在长时间未提交的事务。每周检查是否有异常的大事务记录。定期验证自动 truncate 是否正常工作。13.4 告警阈值参考指标黄色告警红色告警undo 总大小占磁盘比例大于 40%大于 60%History List Length大于 5 万大于 20 万并持续上升单事务运行时长大于 60 秒大于 600 秒单事务修改行数大于 5 万行大于 50 万行purge 滞后事务数大于 10 万大于 50 万且持续增长13.5 容量评估方法在规划新系统或进行容量评估时可以通过以下方法估算 undo 空间的峰值需求统计业务高峰期每分钟的 UPDATE 和 DELETE 行数。根据单行平均大小估算每分钟产生的 undo 数据量。结合最长事务的持续时间计算单事务可能产生的最大 undo 量。在峰值基础上乘以 1.5 到 2 倍的安全系数作为 undo 空间规划的容量基准。例如假设业务高峰期每分钟修改 10 万行平均每行 200 字节则每分钟产生约 20 MB 的 undo 数据。如果最长事务可能持续 30 分钟则最坏情况下单事务就需要约 600 MB 的 undo 空间。再乘以安全系数后单 undo 表空间规划为 2 GB 左右比较稳妥。14. 常见问题 FAQ14.1 为什么 undo 表空间只有增大不会自动变小主要原因是没有启用 innodb_undo_log_truncate或者虽然启用但条件不满足导致 truncate 从未真正执行。请检查该参数状态、undo 表空间数量以及是否存在阻塞 truncate 的长事务。14.2 undo 表空间多大算正常没有绝对标准与业务写入模式和事务特征有关。一个健康的标准是undo 表空间在业务平稳时保持在 innodb_max_undo_log_size 设定的阈值附近并且能够通过自动 truncate 周期性收缩。如果单个 undo 表空间长期超过阈值数倍需要排查明细。14.3 可以物理直接删除过大的 undo 文件吗绝对不可以。直接删除 undo 文件会导致数据库无法启动甚至造成数据损坏。正确做法是先通过 SET INACTIVE 让 InnoDB 安全地对该表空间执行 truncate然后再做后续处理。14.4 为什么 kill 掉长事务后 undo 还没有收缩kill 长事务后InnoDB 需要先完成对该事务的回滚然后由 purge 线程逐步清理其 undo 记录。这个过程不是瞬时完成的需要一定时间。当 purge 完成后undo 表空间的大小才会在下次 truncate 时收缩。请耐心观察 History List Length 的变化趋势。14.5 MySQL 8.0 至少需要几个 undo 表空间官方推荐至少维护两个 active 状态的 undo 表空间以便轮换执行 truncate。如果只有单个 undo 表空间它将无法被设置为 inactive也就无法进行 truncate 收缩。15. 总结MySQL 的 Undo Log 机制贯穿了事务回滚、MVCC 并发控制、崩溃恢复和 purge 清理四大核心能力。它的配置与运维质量直接影响着数据库的稳定性和磁盘空间的使用效率。本文围绕 undo log 的核心原理、存储结构、参数配置、purge 机制、监控诊断、空间收缩以及故障处理梳理了一条从理论到实战的完整知识链路。在生产环境中做好 undo log 管理并不需要复杂的技巧关键在于建立完善的监控、识别并治理长事务和大事务、合理配置 truncate 与 purge 参数并养成定期巡检的习惯。希望这份配置实战指南能够帮助你在日常运维中少走弯路让 undo 表空间始终处于可控的健康范围。后续如果需要深入了解 MVCC 的实现细节、Redo Log 的优化方法或者主从复制与 undo 空间的关联问题可以继续查阅 MySQL 官方文档和相关的源码分析资料。 MySQL Undo Log 配置实战指南：参数优化与操作手册
1. Undo Log 概述在 MySQL 的 InnoDB 存储引擎体系中Undo Log 是最容易被忽视、却最容易在线上引发严重故障的组件之一。很多数据量大、写入并发高的系统最终不是倒在了磁盘容量上而是倒在了几十 GB 甚至上百 GB 的 undo 表空间上。理解 Undo Log 的工作原理、掌握其参数配置与日常运维方法是每一位 MySQL DBA 和资深后端开发者的必修课。Undo Log 是 InnoDB 为支持事务回滚和多版本并发控制而维护的一种逻辑日志。它与 Redo Log 有本质区别Redo Log 是物理日志记录的是「数据页上的某个位置发生了什么变化」用于崩溃恢复而 Undo Log 是逻辑日志记录的是「某条数据被修改前的旧值」用于事务回滚和 MVCC 读取。简单来说Redo Log 负责「重做」Undo Log 负责「撤销」。当一条 SQL 语句执行 UPDATE、DELETE 或 INSERT 操作时InnoDB 会在修改数据页之前先把修改前的数据镜像写入 Undo Log。这样设计的目的十分明确如果事务最终需要回滚数据库可以依据 Undo Log 把数据恢复成修改前的状态如果事务提交后其它并发事务还需要读取该行的旧版本Undo Log 又能支撑 MVCC 快照读的实现。因此Undo Log 并非只在回滚时有用它是 InnoDB MVCC 机制的底层支撑。只要数据库存在并发事务和一致性读需求Undo Log 就必须长期保留直到没有任何事务再需要访问这些旧版本数据为止。这一特性也直接造成了 Undo Log 常见的「只增不减、容易膨胀」的问题。2. Undo Log 的核心作用要真正理解 Undo Log 的配置与优化首先要搞清楚它到底承担了哪些职责。概括起来Undo Log 主要有四大作用事务回滚、MVCC 多版本并发控制、崩溃恢复阶段的未提交事务回滚以及 purge 清理的数据来源。2.1 事务回滚事务回滚是 Undo Log 最直观的作用。当用户显式执行 ROLLBACK 语句或者事务因为异常被强制回滚时InnoDB 需要把该事务修改过的数据恢复到修改之前的状态。这个「修改之前的状态」就记录在 Undo Log 中。例如下面的场景START TRANSACTION; UPDATE account SET balance balance - 100 WHERE user_id 1001; UPDATE account SET balance balance 100 WHERE user_id 1002; ROLLBACK;如果第二条 UPDATE 执行失败或者用户回滚InnoDB 会根据第一条 UPDATE 产生的 Undo Log把 user_id 为 1001 的账户余额恢复到扣减 100 元之前的值。整个回滚过程依赖的就是事务执行期间写入的 Undo 记录。2.2 MVCC 多版本并发控制MVCC 是 InnoDB 实现高并发读的核心机制。它允许普通的 SELECT 语句在不加锁、不阻塞写操作的情况下读取到事务开始时的一致性快照。实现这一能力的关键就是 Undo Log 中保存的行历史版本。InnoDB 的聚簇索引记录中每一行都包含两个隐藏列DB_TRX_ID 和 DB_ROLL_PTR。DB_TRX_ID 表示最后一次修改该行的事务 IDDB_ROLL_PTR 则是指向该行上一个版本在 Undo Log 中位置的指针。当一个一致性读事务需要读取某行数据时如果发现该行的最新版本是在本事务开始之后才提交的就会顺着 DB_ROLL_PTR 指针在 Undo Log 中查找符合快照要求的旧版本。这意味着只要还有事务可能读取某个旧版本对应的 Undo Log 就不能被清理。这也解释了为什么长事务会导致 Undo Log 急剧膨胀——因为长事务持续持有旧的一致性视图使得大量 Undo 记录无法被 purge。2.3 崩溃恢复当数据库意外宕机后重启InnoDB 会利用 Redo Log 把已提交事务的修改重做到数据页上。但此时可能存在一部分未提交事务的修改也被重做了。为了把这部分未提交事务的修改撤销掉InnoDB 需要扫描 Undo Log找出所有未提交事务并执行回滚操作。这个阶段叫做 crash recovery 中的 rollback of uncommitted transactions。因此Undo Log 不仅在正常运行中承担回滚职责在崩溃恢复阶段同样是保证数据一致性的关键一环。如果 Undo 表空间损坏或者空间不足崩溃恢复过程可能无法顺利完成甚至导致数据库无法正常启动。2.4 支撑 purge 操作当一条 DELETE 语句执行时InnoDB 并不会立刻把该行数据从磁盘上物理删除而是先在该行上打一个删除标记真正的物理删除由后台的 purge 线程完成。purge 线程依据的就是 Undo Log 中的删除记录。同理UPDATE 操作本质上也是「标记旧版本 插入新版本」的过程旧版本的物理清理同样依赖 purge。一旦 purge 操作完成对应的 Undo 记录就不再被任何事务需要可以被释放并供后续重用。因此purge 的效率直接决定了 Undo 表空间能否得到有效回收。3. Undo Log 的存储结构理解 Undo Log 的存储结构是进行参数优化和空间诊断的基础。不同 MySQL 版本的存储形式差异较大下面分别介绍传统回滚段和新版独立 Undo 表空间两种体系。3.1 回滚段与 Undo 段在传统架构中InnoDB 通过回滚段来组织 Undo 记录。一个回滚段可以管理一组 undo slot每个 undo slot 对应一个 undo 段。undo 段由若干 undo 页面组成这些页面按照链表的方式组织形成一个 undo 日志的链式结构。每个事务在执行写操作时需要从回滚段中分配一个 undo 段。事务修改的数据越多undo 段中写入的 undo 页面就越多。如果写入的量超过了当前 undo 段所能容纳的范围InnoDB 会继续申请新的页面并追加到链表尾部。在 MySQL 5.6 及更早版本中回滚段存储在一个共享的表空间内。到了 MySQL 5.7 和 8.0InnoDB 支持使用独立的 undo 表空间将回滚段从系统表空间中分离出来从而支持更加灵活的 truncate 和空间管理。3.2 独立 Undo 表空间MySQL 5.7 开始支持独立的 undo 表空间默认情况下 undo 日志存放在独立的 undo 表空间文件中。MySQL 8.0 则彻底将 undo 日志从系统表空间中移除默认创建两个独立的 undo 表空间文件undo_001 和 undo_002。独立 undo 表空间的好处十分明显便于收缩支持在线 truncate可以把膨胀的 undo 表空间物理文件收缩回初始大小。便于管理undo 文件可以被移动到指定的目录便于分散 IO 压力。故障隔离undo 表空间的问题不会直接影响系统表空间中的其它数据结构。在 MySQL 8.0 中还可以通过 CREATE UNDO TABLESPACE 语句动态创建额外的 undo 表空间并且可以通过 ALTER UNDO TABLESPACE 语句将其设置为活动或非活动状态配合 truncate 进行空间收缩。3.3 Undo 记录的两种类型InnoDB 的 undo 记录根据操作类型可以分为 INSERT undo 和 UPDATE undo 两大类。INSERT undo 对应 INSERT 操作的撤销信息这部分 info 通常只在事务提交后即可删除因为新插入的行如果没有提交其它事务看不到不存在 MVCC 需求。而 UPDATE undo 对应 UPDATE 和 DELETE 操作的撤销信息这部分需要根据事务隔离级别和并发读需求保留更长时间。由于 UPDATE undo 与 MVCC 直接相关它才是造成 undo 表空间膨胀的罪魁祸首。因此在诊断 undo 空间问题时重点要关注是否存在大量未 purge 的 UPDATE undo 记录。4. Undo 表空间体系与文件分布在深入参数配置之前有必要先厘清不同版本下 undo 表空间文件的分布情况和命名规律这样在排查问题时才能迅速定位文件位置。4.1 MySQL 5.6 及之前在 MySQL 5.6 及更早版本中undo 日志存储于共享的 ibdata 系统表空间中。这种设计存在一个非常头疼的问题ibdata 文件只会增大不会收缩。即使事务已经提交、undo 记录已经被 purge这些空间也只能被后续的 undo 记录重用却无法从物理上释放。很多老系统在运行数年后ibdata1 文件从初始的 10 MB 膨胀到数十 GB最终只能通过重建实例来解决。4.2 MySQL 5.7MySQL 5.7 自 5.7.5 版本开始支持独立 undo 表空间但默认配置在部分发行版中仍然使用系统表空间。如果希望使用独立 undo 表空间需要在初始化实例时显式指定 innodb_undo_tablespaces 参数。需要注意的是MySQL 5.7 中该参数只有在初始化时才能生效实例创建后无法修改。MySQL 5.7 的独立 undo 表空间文件默认位于数据目录下命名为 undo001、undo002 等。此外MySQL 5.7 还支持设置 innodb_undo_log_truncate 参数当 undo 表空间超过阈值时自动执行 truncate 收缩。4.3 MySQL 8.0MySQL 8.0 对 undo 表空间进行了全面重构默认创建两个独立 undo 表空间 undo_001 和 undo_002不再使用系统表空间存放 undo。支持在线动态创建和删除 undo 表空间。支持在多个 undo 表空间之间动态切换活动状态。支持将 undo 表空间设置为 inactive 后进行 truncate整个过程在线完成。MySQL 8.0 的 undo 表空间命名以 undo_ 开头后面跟数字序号。用户创建的自定义 undo 表空间需要以 .ibu 为扩展名。例如CREATE UNDO TABLESPACE undo_003 ADD DATAFILE undo_003.ibu;这一机制让 DBA 可以像管理普通表空间一样管理 undo 表空间极大地增强了运维灵活性。5. 核心配置参数详解本节是整篇指南的重中之重。我们将逐一剖析与 undo log 相关的核心参数包括参数含义、默认值、适用场景、调优建议以及不同版本之间的差异。5.1 innodb_undo_directory该参数用于指定 undo 表空间文件的存放目录。默认情况下undo 表空间文件存放在数据目录中。如果业务写入量较大建议将 undo 表空间放到独立的、高性能的存储设备上以降低与数据文件和 redo log 之间的 IO 争用。配置示例[mysqld] innodb_undo_directory /data/mysql_undo/需要注意的是该参数在 MySQL 5.7 中只有在初始化实例时指定才有效在 MySQL 8.0 中创建 undo 表空间时也可以通过 ADD DATAFILE 子句指定绝对路径但不建议将文件路径直接放在 innodb_undo_directory 之外以免造成管理混乱。5.2 innodb_undo_tablespaces该参数用于指定独立 undo 表空间的数量。在 MySQL 5.7 中它控制初始化时创建的 undo 表空间文件数量在 MySQL 8.0 中该参数已经被废弃改为使用 CREATE UNDO TABLESPACE 动态管理。在 MySQL 5.7 中默认值为 0即不使用独立 undo 表空间而是沿用系统表空间。如果希望启用独立 undo 表空间需要在初始化实例前设置[mysqld] innodb_undo_tablespaces 3在 MySQL 8.0 中官方推荐至少维护两个活动状态的 undo 表空间以便轮换执行 truncate。如果存在单个表空间长期无法切换 inactive 的情况可能需要创建更多的 undo 表空间进行轮换。5.3 innodb_undo_log_truncate该参数控制是否启用 undo 表空间的自动 truncate 收缩功能。默认值为 ONMySQL 8.0或 OFFMySQL 5.7 默认关闭需要手动开启。当启用该功能后InnoDB 会定期检查 undo 表空间的大小如果某个 undo 表空间超过阈值就会尝试将其标记为 inactive并执行 truncate 操作把物理文件收缩到初始大小。配置示例[mysqld] innodb_undo_log_truncate ON启用自动 truncate 前需要满足几个前提实例中至少存在两个 undo 表空间innodb_undo_tablespaces 大于等于 2MySQL 5.7undo 表空间支持在线切换 inactive。否则 truncate 无法执行。5.4 innodb_max_undo_log_size该参数定义了单个 undo 表空间触发自动 truncate 的大小阈值。默认值为 1 GB。当某个 undo 表空间的大小超过该阈值并且该表空间可以被标记为 inactive 时InnoDB 就会执行 truncate。参数支持的单位有 KB、MB、GB。配置示例[mysqld] innodb_max_undo_log_size 4G需要注意的是innodb_max_undo_log_size 只是一个触发阈值的软限制undo 表空间的实际大小可能暂时超过该值。此外该参数过小时会导致 truncate 频繁触发带来额外的 IO 开销和性能抖动过大则会失去空间控制的意义。通常建议根据业务的写入峰值和单次大事务规模来综合设定常见经验值为 1 GB 到 8 GB 之间。5.5 innodb_purge_threads该参数用于指定后台 purge 线程的数量。purge 线程负责清理被标记删除的记录并释放不再被任何事务需要的 undo 记录。默认值为 4MySQL 8.0。如果业务环境中 UPDATE 和 DELETE 操作非常频繁purge 速度赶不上产生速度就会造成 undo 空间持续增长。当数据库出现以下现象时可以考虑增加 purge 线程数量History List Length 持续处于高位且没有下降趋势。undo 表空间不断增大即便没有大的长事务。SHOW ENGINE INNODB STATUS 中显示 purge 累积严重滞后。配置示例[mysqld] innodb_purge_threads 8该参数的上限为 32但并不是越大越好。purge 线程过多会增大对数据页和 undo 页的并发访问压力甚至与业务读写争抢资源。一般建议从 4 开始逐步调高结合实际监控数据确定最优值。5.6 innodb_purge_batch_size该参数定义了每个 purge 批次最多能处理和提交的 undo 记录数量。默认值为 300。适当增大该值可以提高每次 purge 的处理效率减少 purge 提交的频率从而提升历史版本清理的速度。但如果设置过大可能导致 purge 操作单次占用过多资源引起业务响应时间的毛刺。配置示例[mysqld] innodb_purge_batch_size 1000建议在写入压力大、历史版本堆积严重时适度调大该参数同时密切观察系统负载和业务延迟避免调优过度。5.7 innodb_rollback_segments该参数用于指定每个 undo 表空间中的回滚段数量。默认值为 128。回滚段数量决定了数据库中同时能够进行的并发写入事务的上限。每个回滚段可以包含 1024 个 undo slot因此默认配置能够支撑相当可观的并发事务数。在 MySQL 8.0 中用户无法直接修改该参数的默认值 128。这个参数更多是用于理解并发事务与 undo 资源的对应关系。正常情况下无需调整但在极高高并发的写入场景下如果怀疑并发事务数已经逼近回滚段上限可以通过查看视图来验证。5.8 innodb_undo_log_encrypt该参数用于控制是否对 undo 表空间进行加密。从安全合规的角度看undo 日志中同样保存着业务数据的旧版本信息如果磁盘泄露undo 文件同样可能造成敏感数据泄露。因此在启用了>[mysqld] innodb_undo_log_encrypt ON该参数支持动态修改。修改后新创建的 undo 表空间会自动启用加密已存在的 undo 表空间需要在执行 truncate 时才能完成加密方式的转换。5.9 参数汇总表参数名默认值作用简述MySQL 8.0 建议值innodb_undo_directory数据目录undo 文件存放目录独立高速存储目录innodb_undo_tablespaces8.0 已废弃独立 undo 表空间数量使用动态管理innodb_undo_log_truncateON8.0是否自动 truncateONinnodb_max_undo_log_size1 GBtruncate 触发阈值1 GB 到 8 GBinnodb_purge_threads4purge 线程数4 到 16innodb_purge_batch_size300每批 purge 记录数300 到 2000innodb_rollback_segments128每表空间回滚段数保持默认innodb_undo_log_encryptOFFundo 文件加密按安全要求开启6. Purge 机制深度解析Purge 机制是理解 undo 空间管理的核心。很多 undo 空间持续膨胀的问题本质上都是 purge 不及时造成的。本节从原理到实践完整解析 purge 的工作流程和优化方法。6.1 purge 的触发时机当一个事务提交后它的 undo 记录并不会立即被删除因为可能会有更早启动的读事务仍然需要读取这些旧版本数据。InnoDB 使用 history list 来维护所有「已经提交、但尚未清理」的 undo 记录。当 purge 线程运行时它会根据系统中所有活跃读事务的最老快照确定哪些 undo 记录已经不可能再被访问然后将其清理。purge 的触发时机主要包括后台 purge 线程周期性地唤醒并执行清理。当前系统中需要分配新的 undo 页时触发一定量的 purge 以释放空间。InnoDB 内部根据 history list 长度决定是否加大 purge 强度。6.2 History List Length 的意义History List Length 是诊断 undo 问题最重要的指标之一。它表示当前系统中尚未被 purge 处理的 undo 记录数量。该值可以通过以下命令查看SHOW ENGINE INNODB STATUS\G在输出结果中查找 History list length 字段------------ TRANSACTIONS ------------ Trx id counter 42356789 Purge done for trxs n:o 42356100 undo n:o 0 state: running but idle History list length 2893正常情况下History List Length 会在事务提交后逐渐回落。如果该值长期维持在高位或者持续单调递增说明 purge 已经严重滞后需要立即排查原因。常见原因包括长事务阻塞了 purge 的推进、purge 线程资源不足、大事务一次性产生了海量 undo 记录等。6.3 purge 滞后的排查思路当发现 History List Length 过高时可以按照以下顺序排查-- 1. 查找当前最老的事务 SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.innodb_trx ORDER BY trx_started ASC LIMIT 20;这条 SQL 可以找出启动时间最早的事务。如果一个事务启动了数小时乃至数天它就会一直持有最老的快照导致 purge 无法清理其启动之后产生的所有 undo 记录。-- 2. 查找长时间未提交的事务 SELECT trx_id, trx_started, trx_mysql_thread_id, trx_state, NOW() - trx_started AS duration, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING ORDER BY trx_started ASC;对于确认已经僵死的长事务应尽快与业务方确认后执行 kill 或者回滚。-- 3. 查看当前 purge 是否处于运行状态 SHOW GLOBAL STATUS LIKE Innodb_purge%;如果相关状态值长时间没有变化可能意味着 purge 线程卡住需要进一步检查是否存在资源竞争问题。7. Undo 表空间监控与诊断完善的监控体系是避免 undo 空间故障的第一道防线。本节介绍如何通过系统视图、状态变量和操作系统命令对 undo 表空间进行持续监控和快速诊断。7.1 查看 undo 表空间基本情况在 MySQL 8.0 中可以通过 information_schema.INNODB_TABLESPACES 视图查看所有 undo 表空间的信息SELECT SPACE, NAME, FILE_SIZE, ALLOCATED_SIZE, STATE FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE undo%;该查询可以直观地看到每个 undo 表空间当前的物理文件大小、已分配空间以及活动状态。重点关注 FILE_SIZE 是否接近或超过磁盘剩余空间以及 STATE 是否为 active。7.2 查看 undo 相关状态变量以下状态变量与 undo 和 purge 运行状态密切相关SHOW GLOBAL STATUS LIKE Innodb_undo%;常见字段说明Innodb_undo_tablespaces_totalundo 表空间总数。Innodb_undo_tablespaces_implicit初始化时隐式创建的 undo 表空间数量。Innodb_undo_tablespaces_explicit用户显式创建的 undo 表空间数量。Innodb_undo_tablespaces_active当前处于 active 状态的 undo 表空间数量。7.3 监控 History List LengthHistory List Length 是判断 purge 健康度的核心指标。建议在监控系统中采集该指标并设定告警阈值。可以通过下面的查询定期获取SELECT name, count FROM information_schema.innodb_metrics WHERE name IN (trx_rseg_history_len, trx_rseg_current_size);其中 trx_rseg_history_len 对应 History List Length。当该值超过一定阈值例如 10 万并持续上升时应立即告警。7.4 监控 purge 处理效率除了 History List Length 的绝对值外还可以监控 purge 的推进速度SHOW GLOBAL STATUS LIKE Innodb_purge_trx_id_del; SHOW GLOBAL STATUS LIKE Innodb_purge_trx_id_age;其中 Innodb_purge_trx_id_age 表示当前最新事务 ID 与 purge 已完成事务 ID 之间的差值反映 purge 滞后的程度。如果该值不断增大说明 purge 速度跟不上事务产生的速度。8. Undo 表空间收缩实战当 undo 表空间已经膨胀到很大时手动或自动执行 truncate 是回收空间的唯一有效手段。本节详细介绍 MySQL 8.0 中 undo 表空间收缩的完整流程和注意事项。8.1 自动 truncate 的前提条件自动 truncate 需要同时满足以下条件innodb_undo_log_truncate 设置为 ON。存在至少两个活动状态的 undo 表空间MySQL 5.7或至少两个可轮换的表空间MySQL 8.0。目标 undo 表空间的大小超过 innodb_max_undo_log_size。目标 undo 表空间可以被安全地标记为 inactive即其中没有未提交事务和未被 purge 的旧版本数据。8.2 MySQL 8.0 手动 truncate 流程当自动 truncate 未触发或者希望立即收缩某个已经膨胀的 undo 表空间时可以手动执行以下流程-- 1. 查看当前所有 undo 表空间状态 SELECT SPACE, NAME, FILE_SIZE, STATE FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE undo%;-- 2. 将目标 undo 表空间设置为 inactive ALTER UNDO TABLESPACE undo_001 SET INACTIVE;需要注意该命令只有在目标 undo 表空间中没有活跃事务时才能成功。如果表空间中仍有事务未提交或旧版本数据未被 purge命令会等待或失败。-- 3. 在操作系统层面确认文件大小 -- 在数据目录下执行以 Linux 为例 ls -lh undo_001.ibu-- 4. 重新激活 undo 表空间 ALTER UNDO TABLESPACE undo_001 SET ACTIVE;在 inactive 状态下InnoDB 会自动对该 undo 表空间执行 truncate 操作。再次查看到文件大小时会发现已经收缩到初始大小。最后将其重新置为 active 即可。8.3 无法 truncate 时的排查步骤如果执行 SET INACTIVE 一直无法成功通常是有事务或旧版本数据仍然占用该 undo 表空间。此时需要-- 查找正在使用该 undo 表空间的活跃事务 SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING ORDER BY trx_started ASC;将查出来的长事务处理掉后再尝试执行 SET INACTIVE。如果还是失败可以检查是否有未结束的备份会话、复制线程或 XA 事务占用 undo 资源。9. 大事务与长事务的排查与治理大事务和长事务是 undo 空间膨胀的最主要原因。本节重点介绍如何发现、定位和处理这些问题从源头减少 undo 空间的异常消耗。9.1 大事务对 undo 的影响一个事务修改的行数越多产生的 undo 记录就越多undo 表空间就会相应增大。如果单个事务一次性修改了上亿行数据它产生的 undo 记录甚至可能达到数十 GB。更麻烦的是这个事务在提交之前它的所有 undo 记录都不能被 purgeundo 表空间会被持续占用。9.2 发现大事务的方法-- 列出当前所有活跃事务并查看它们修改的行数 SELECT trx_id, trx_started, trx_rows_modified, trx_state, trx_query FROM information_schema.innodb_trx WHERE trx_rows_modified 0 ORDER BY trx_rows_modified DESC LIMIT 20;trx_rows_modified 字段表示事务到目前为止修改的行数。该值过大的事务就是需要重点关注的大事务。建议在监控系统中对此字段进行持续采集一旦发现超过阈值例如 10 万行立即告警。9.3 长事务的识别与处理长事务的识别除了通过 trx_started 字段判断事务运行时长外还要特别注意那些启动时间早、但当前处于空闲状态的事务。这类事务可能来自应用层开启了事务却没有及时提交或回滚。-- 查找运行时间超过 60 秒的事务 SELECT trx_id, trx_mysql_thread_id, trx_started, NOW() - trx_started AS duration, trx_state, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING AND NOW() - trx_started 60 ORDER BY trx_started ASC;对于确认是应用层泄漏的事务需要定位到对应的 MySQL 线程 ID 并谨慎处理-- 查看该事务对应的会话连接信息 SELECT * FROM information_schema.processlist WHERE ID trx_mysql_thread_id;确认连接来源后协同业务方执行 kill 或回滚。不要贸然 kill 正在执行重要业务操作的事务以免造成业务数据不一致。9.4 从代码层治理大事务彻底治理大事务问题最终还是要在应用代码层做文章。常见治理思路包括将大批量 UPDATE 或 DELETE 操作拆分为多个小批次执行每批次提交一次事务。在批量任务执行间隙主动释放事务避免长时间持有。将非必要的 SELECT 移出事务范围减少事务持续时间。对热点行更新进行限流和削峰避免同一时间堆积大量并发修改。例如将一次性删除 1000 万行的操作拆分为每批 1 万行-- 分批删除示例存储过程片段 DELIMITER // CREATE PROCEDURE purge_big_table() BEGIN DECLARE affected_rows INT DEFAULT 1; WHILE affected_rows 0 DO START TRANSACTION; DELETE FROM big_table WHERE create_time 2025-01-01 LIMIT 10000; SET affected_rows ROW_COUNT(); COMMIT; DO SLEEP(0.5); END WHILE; END // DELIMITER ;这种分批处理方式可以显著降低单事务的 undo 压力同时也降低了对主从复制的延迟影响。10. Undo 空间相关的典型故障与处理线上系统一旦遇到 undo 空间问题往往表现为磁盘告警、业务写入变慢甚至数据库直接不可用。本节总结几类典型故障的排查和处理全过程。10.1 磁盘空间被 undo 占满故障现象监控告警显示磁盘使用率接近 100%排查后发现 undo 表空间文件异常巨大。可能是某个大事务正在持续执行也可能是长事务阻塞了 purge。处理步骤立即确认是否存在正在执行的大事务。如果有先评估能否等待其完成若事务已经失控与业务方沟通后执行 kill。确认是否存在长时间未提交的事务将其清理掉。检查 purge 线程是否在正常工作如果 History List Length 巨大适当调大 purge 相关参数。临时扩大磁盘空间或者将 undo 文件迁移到空间充足的目录避免数据库因磁盘满而挂起。待 undo 膨胀问题缓解后执行 truncate 收缩 undo 表空间。10.2 数据库启动时 undo 表空间报错故障现象实例重启时错误日志出现 undo 表空间相关的报错例如文件缺失、损坏或空间不足导致实例无法启动。处理思路检查错误日志中的具体报错信息确认是哪个 undo 表空间出现问题。确认该 undo 表空间文件是否存在于指定目录权限是否正确。检查磁盘剩余空间是否足够存放 undo 临时文件。如果是个别 undo 表空间损坏可以尝试将其删除后重新创建但需谨慎评估数据一致性风险建议先咨询官方支持或资深 DBA。切勿在没有备份的情况下随意删除 undo 表空间文件否则可能导致数据不一致甚至实例无法启动。10.3 purge 卡住导致 undo 膨胀故障现象事务提交正常但 undo 表空间持续增大SHOW ENGINE INNODB STATUS 中 History list length 持续攀升purge 相关状态不再变化。排查要点确认 purge 线程是否被阻塞。可能的原因是某个锁等待或资源竞争。检查 innodb_purge_threads 参数是否过低尝试适度调高。观察系统 CPU、IO 负载确认 purge 是否因为资源不足而无法推进。检查是否存在极老的事务快照阻止了 purge 清理后续 undo 记录。通常只要清除了最老的长事务History List Length 就会迅速回落undo 表空间也会在后续的 truncate 中收缩。11. 版本演进与差异对照了解不同 MySQL 版本在 undo 管理上的差异有助于在升级或迁移过程中避免踩坑。下表总结了 MySQL 5.6、5.7 和 8.0 三个主要版本的关键差异。特性MySQL 5.6MySQL 5.7MySQL 8.0undo 存放位置系统表空间 ibdata支持独立表空间独立表空间undo 表空间管理不可单独管理初始化时固定数量动态创建与删除在线 truncate不支持支持自动 truncate支持自动与手动轮换 truncateundo 空间收缩需要重建实例自动 truncate手动 SET INACTIVE 后 truncate加密支持不支持支持全面支持默认 undo 文件无独立文件undo001 等undo_001、undo_002从 5.6 升级到 8.0 时最明显的变化就是 undo 表空间的结构和管理方式。升级前需要确认目标版本的 undo 表空间数量和配置避免升级后因为配置不兼容导致实例无法启动。12. Undo Log 运维操作手册本节提供一份可随时查阅的操作手册覆盖日常运维中最常用的 undo 相关操作。12.1 查看 undo 表空间信息-- 查看所有 undo 表空间 SELECT SPACE, NAME, FILE_SIZE, ALLOCATED_SIZE, STATE FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE undo% ORDER BY SPACE;12.2 动态创建 undo 表空间-- 创建新的 undo 表空间 CREATE UNDO TABLESPACE undo_003 ADD DATAFILE undo_003.ibu;创建完成后新表空间默认为 active 状态InnoDB 会自动将新事务分布到其中。12.3 删除 undo 表空间-- 先将其设置为 inactive ALTER UNDO TABLESPACE undo_003 SET INACTIVE; -- 再删除 DROP UNDO TABLESPACE undo_003;注意undo 表空间只有在 inactive 状态下才能被删除。如果其中存在活跃事务或未被 purge 的旧版本数据SET INACTIVE 会等待。12.4 手动收缩 undo 表空间-- 将目标表空间设为 inactive触发自动 truncate ALTER UNDO TABLESPACE undo_001 SET INACTIVE; -- 观察文件大小已收缩后重新激活 ALTER UNDO TABLESPACE undo_001 SET ACTIVE;12.5 修改 undo 相关参数-- 动态开启自动 truncate SET GLOBAL innodb_undo_log_truncate ON; -- 动态调整最大 undo 大小阈值8.0 支持动态修改 SET GLOBAL innodb_max_undo_log_size 4294967296; -- 动态调整 purge 线程数 SET GLOBAL innodb_purge_threads 8;需要注意的是部分参数修改后只对新生成的 undo 记录生效对已有 undo 数据不会立即产生影响配置变更应结合监控数据逐步验证效果。12.6 批量查询活跃事务-- 查询当前所有未提交事务 SELECT trx_id, trx_state, trx_started, trx_rows_modified, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx WHERE trx_state RUNNING ORDER BY trx_started ASC;建议将这类查询固化到监控脚本中定期执行并记录结果便于问题发生后回溯分析。13. 最佳实践与优化建议结合前文的分析本节总结出一套在生产环境中经过验证的 undo log 运维最佳实践供读者直接参考落地。13.1 存储规划为 undo 表空间单独规划存储目录与数据目录和 binlog 分开减少 IO 争用。优先使用 SSD 或高性能 NVMe 盘存放 undo 文件因为 undo 的读写具有随机性。预留充足的磁盘空间按照日常写入量的 2 到 3 倍评估 undo 峰值占用。13.2 参数配置基线对于大多数中等规模业务可以采用以下参数基线[mysqld] innodb_undo_log_truncate ON innodb_max_undo_log_size 4G innodb_purge_threads 8 innodb_purge_batch_size 600对于写入特别频繁的系统可以适当调高 purge 线程数和批量大小但要注意避免过度调优导致资源争抢。13.3 日常巡检清单每日检查 undo 表空间文件大小及磁盘剩余空间。每日检查 History List Length 的峰值和趋势。每日检查是否存在长时间未提交的事务。每周检查是否有异常的大事务记录。定期验证自动 truncate 是否正常工作。13.4 告警阈值参考指标黄色告警红色告警undo 总大小占磁盘比例大于 40%大于 60%History List Length大于 5 万大于 20 万并持续上升单事务运行时长大于 60 秒大于 600 秒单事务修改行数大于 5 万行大于 50 万行purge 滞后事务数大于 10 万大于 50 万且持续增长13.5 容量评估方法在规划新系统或进行容量评估时可以通过以下方法估算 undo 空间的峰值需求统计业务高峰期每分钟的 UPDATE 和 DELETE 行数。根据单行平均大小估算每分钟产生的 undo 数据量。结合最长事务的持续时间计算单事务可能产生的最大 undo 量。在峰值基础上乘以 1.5 到 2 倍的安全系数作为 undo 空间规划的容量基准。例如假设业务高峰期每分钟修改 10 万行平均每行 200 字节则每分钟产生约 20 MB 的 undo 数据。如果最长事务可能持续 30 分钟则最坏情况下单事务就需要约 600 MB 的 undo 空间。再乘以安全系数后单 undo 表空间规划为 2 GB 左右比较稳妥。14. 常见问题 FAQ14.1 为什么 undo 表空间只有增大不会自动变小主要原因是没有启用 innodb_undo_log_truncate或者虽然启用但条件不满足导致 truncate 从未真正执行。请检查该参数状态、undo 表空间数量以及是否存在阻塞 truncate 的长事务。14.2 undo 表空间多大算正常没有绝对标准与业务写入模式和事务特征有关。一个健康的标准是undo 表空间在业务平稳时保持在 innodb_max_undo_log_size 设定的阈值附近并且能够通过自动 truncate 周期性收缩。如果单个 undo 表空间长期超过阈值数倍需要排查明细。14.3 可以物理直接删除过大的 undo 文件吗绝对不可以。直接删除 undo 文件会导致数据库无法启动甚至造成数据损坏。正确做法是先通过 SET INACTIVE 让 InnoDB 安全地对该表空间执行 truncate然后再做后续处理。14.4 为什么 kill 掉长事务后 undo 还没有收缩kill 长事务后InnoDB 需要先完成对该事务的回滚然后由 purge 线程逐步清理其 undo 记录。这个过程不是瞬时完成的需要一定时间。当 purge 完成后undo 表空间的大小才会在下次 truncate 时收缩。请耐心观察 History List Length 的变化趋势。14.5 MySQL 8.0 至少需要几个 undo 表空间官方推荐至少维护两个 active 状态的 undo 表空间以便轮换执行 truncate。如果只有单个 undo 表空间它将无法被设置为 inactive也就无法进行 truncate 收缩。15. 总结MySQL 的 Undo Log 机制贯穿了事务回滚、MVCC 并发控制、崩溃恢复和 purge 清理四大核心能力。它的配置与运维质量直接影响着数据库的稳定性和磁盘空间的使用效率。本文围绕 undo log 的核心原理、存储结构、参数配置、purge 机制、监控诊断、空间收缩以及故障处理梳理了一条从理论到实战的完整知识链路。在生产环境中做好 undo log 管理并不需要复杂的技巧关键在于建立完善的监控、识别并治理长事务和大事务、合理配置 truncate 与 purge 参数并养成定期巡检的习惯。希望这份配置实战指南能够帮助你在日常运维中少走弯路让 undo 表空间始终处于可控的健康范围。后续如果需要深入了解 MVCC 的实现细节、Redo Log 的优化方法或者主从复制与 undo 空间的关联问题可以继续查阅 MySQL 官方文档和相关的源码分析资料。