log sequence number 与 log flushed up to 的差值即为当前未刷盘 redo 字节数，持续 >10mb 且缓慢增长表明 redo 写入压力大或刷盘滞后；该值需手动多次执行 show engine innodb status 观察趋势，是唯一实时反映 redo 活跃水位的原生指标。
直接看 SHOW ENGINE INNODB STATUS 的 LOG 小节，用 Log sequence number 减 Log flushed up to，差值就是当前未刷盘 Redo 字节数——这才是最贴近真实写入压力的指标，不是查表、不是算 SQL 数量、更不是看磁盘 IO util。
怎么从 SHOW ENGINE INNODB STATUS 提取实时 Redo 压力
这个命令不保存、不聚合、只反映执行瞬间状态，但它是唯一能直接看到 Redo 活跃水位的原生入口。重点盯住 LOG 小节里两行：
-
Log sequence number 1234567890：已分配 LSN，代表 Redo 总写入量（含 buffer 和已落盘部分） -
Log flushed up to 1234556789：已 fsync 到磁盘的 LSN
差值 ≈ 当前堆积在 OS cache 或 buffer 中、尚未真正落盘的 Redo 字节数。持续 > 10MB 且缓慢上涨，说明刷盘跟不上写入节奏；如果差值在几 MB 内频繁抖动，属于正常缓冲行为。
注意：SHOW ENGINE INNODB STATUS 默认每秒刷新一次内部计数器，但输出本身是快照。想观察趋势，得手动间隔几秒反复执行，不能依赖单次结果下结论。
为什么不能用 innodb_log_file_size 除以事务数来估算
很多人误把 innodb_log_file_size 当成“单事务日志容量”，其实它只是物理文件大小上限，和单个事务生成多少 Redo 完全无关。真正决定 Redo 产出量的是：
- 修改的数据页数量（UPDATE/INSERT 影响的 page 数越多，Redo 越多）
- 事务内是否包含大字段（如 TEXT/BLOB 更新会触发额外 page 分配和 Redo 记录）
-
innodb_flush_log_at_trx_commit设置：设为 0 或 2 时，Redo 会批量刷盘，单次写入量可能远超单事务实际日志量
比如一个只更新一行 INT 字段的小事务，在 innodb_flush_log_at_trx_commit=1 下可能只产生不到 1KB Redo；但同样语句在 =2 下，若恰逢 buffer 满或定时刷盘触发，可能和另外 20 个事务一起打包写入 50KB —— 这时你算“单事务 Redo”就完全失真。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
如何定位高 Redo 开销的 SQL
Redo 压力最终来自 SQL，但不能只看响应时间。有些快 SQL（如 UPDATE t SET x=x+1 WHERE id BETWEEN 1 AND 10000）会一次性修改数千页，生成巨量 Redo；而慢查询（如复杂 JOIN）可能根本不改数据，Redo 为零。
用 performance_schema.events_statements_summary_by_digest 查：
- 排序字段用
SUM_TIMER_WAIT只能看到耗时，要加SUM_ROWS_AFFECTED和COUNT_STAR组合判断 - 重点关注
SUM_ROWS_AFFECTED / COUNT_STAR均值高的 digest，比如平均每次执行影响 > 100 行的 UPDATE/DELETE - 配合
sys.schema_table_statistics看对应表的rows_updated是否突增，交叉验证
别漏掉隐式事务：AUTOCOMMIT=1 时，每个 INSERT/UPDATE 都是独立事务，高频小事务比低频大事务更容易打满 Redo buffer 并触发频繁刷盘。
trx_rseg_history_len 和 trx_rseg_current_size 能反映 Redo 吗
不能。这两个指标来自 INFORMATION_SCHEMA.INNODB_METRICS，只跟 Undo 相关：trx_rseg_history_len 是历史版本链长度，trx_rseg_current_size 是当前 rollback segment 占用空间。它们上升说明 Undo 活跃度高（长事务、大量 DELETE/UPDATE），间接增加 purge 压力，但和 Redo 写入量无直接换算关系。
如果你发现 Redo 压力大 + Undo 指标也飙升，大概率是同一波业务操作（如大批量 UPDATE）同时产出了大量 Redo 和 Undo；但若只有 Undo 指标涨而 Redo 差值稳定，说明问题出在 purge 滞后或长事务阻塞，不是 Redo 写入瓶颈。
真正容易被忽略的点是：Redo 压力不是孤立存在的。当 innodb_flush_log_at_trx_commit=1 且磁盘 fsync 延迟高时，事务提交会被卡住，表现为你看到的“QPS 下跌”或“COMMIT 耗时飙升”，此时 Log sequence number 和 Log flushed up to 的差值可能不大，但写入能力已经锁死——得去查 iostat -x 1 看 %util 和 await，而不是只盯着 InnoDB 状态。
