SHOW ENGINE INNODB STATUS 的 LOG 小节中，Log sequence number 与 Log flushed up to 的差值近似反映未刷盘 Redo 字节数，差值持续 >10MB 且缓慢增长表明 Redo 写入压力大或刷盘滞后。
如何用 SHOW ENGINE INNODB STATUS 查看实时 Redo 写入量
Redo 日志生成量最直接的观测入口是 InnoDB 的运行时状态，不是靠解析物理日志文件。每次执行 SHOW ENGINE INNODB STATUS，在 LOG 小节里能看到 Log sequence number 和 Log flushed up to 两个关键值，它们的差值近似反映当前未刷盘的 Redo 字节数。
-
Log sequence number是已分配但未必落盘的 LSN（即 Redo 总写入量） -
Log flushed up to是已同步到磁盘的 LSN（即实际刷盘量） - 两者差值持续 > 10MB 且缓慢增长，说明 Redo 写入压力大或刷盘跟不上
- 该命令结果不持久、不可聚合，适合临时诊断，不能用于长期监控
用 INFORMATION_SCHEMA.INNODB_METRICS 监控 Undo 段分配行为
Undo 日志本身不直接暴露“生成字节数”，但事务回滚段（rollback segment）的扩展和重用频率能间接反映 Undo 活跃度。开启指标收集后，innodb_metrics 表里 trx_rseg_history_len 和 trx_rseg_current_size 是核心字段。
- 先执行
SET GLOBAL innodb_monitor_enable = 'all';启用指标 -
trx_rseg_history_len值突增（比如从几百跳到几万），往往对应长事务或大量更新/删除操作 -
trx_rseg_current_size持续增长且不回落，说明 Undo 空间未被及时 purge，可能拖慢后续事务 - 注意：该表默认只统计每秒增量，需自己做时间窗口差值计算，不是原始字节数
为什么 innodb_log_file_size 不等于 Redo 实际日志量
很多人误以为调大 innodb_log_file_size 就能“容纳更多事务”，其实它只是 Redo 文件的单个大小上限，真正决定 Redo 写入节奏的是事务提交频率、修改数据页数量、以及 innodb_flush_log_at_trx_commit 设置。
- 设为
1：每次COMMIT都强制刷盘，Redo 写入更分散但更安全 - 设为
0或2：Redo 先写内存缓冲区（innodb_log_buffer_size），再批量刷盘，单次写入量可能更大、但有丢日志风险 - 即使 log file 很大，如果事务小而密（如高频 insert），Redo 仍会频繁 wrap-around 循环写，不减少 IO 压力
- 调整前务必确认磁盘 IOPS 能力，盲目增大可能让刷盘延迟更明显
用 performance_schema.events_statements_summary_by_digest 定位高 Redo/Undo 开销 SQL
事务日志压力最终来自 SQL，但不能只看执行时间——有些快 SQL（如大批量 UPDATE）反而产生巨量 Redo 和 Undo。借助 digest 表可按归一化语句聚合分析。
- 确保
performance_schema已启用，且events_statements_history_long消耗开关打开 - 查
SUM_ROWS_AFFECTED高 +AVG_TIMER_WAIT低的 digest，往往是“快但脏”的批量操作 - 结合
EVENT_NAME为statement/sql/update或delete的记录重点排查 - 注意：该表不记录 undo 字节数，但
ROWS_AFFECTED× 行平均大小 ≈ 可估算的 Undo 空间占用下限
真正难的是把 Redo/Undo 量映射到具体业务动作——LSN 差值、history length、SQL 影响行数都只是代理指标；当事务混合读写、存在大对象（LOB）、或开启压缩表时，估算偏差会显著放大。
