“innodb: log scan progressed past”只是正常恢复提示，不是错误；它表示innodb启动时扫描redo log以重放checkpoint之后的日志，确保数据一致性，仅当伴随异常日志或启动失败时才需关注。
“InnoDB: Log scan progressed past”只是正常恢复提示，不是错误
这条日志本身不表示故障，而是 InnoDB 启动时做 crash recovery 的常规输出。它说明 MySQL 正在扫描 redo log，试图从最近一次 checkpoint 开始重放日志，以保证数据一致性。
真正的问题藏在它前后几行：比如紧跟着出现 InnoDB: Database was not shut down normally! 或 InnoDB: Database page corruption on disk，才说明上次关机异常或磁盘损坏。
- 正常场景：机器意外断电、kill -9 mysqld、系统崩溃后重启，都会触发这个流程
- 关键判断依据不是这行日志，而是后续是否卡住、报 assertion failure、checksum mismatch 或直接 abort
- 如果只看到这行，然后 MySQL 成功启动，可以忽略 —— 它只是告诉你“我在修数据”，不是“我修坏了”
为什么它总和 checkpoint lsn 一起出现？
Log scan progressed past the checkpoint lsn XXX 中的 lsn（log sequence number）是 InnoDB 日志内部的递增计数器，代表写入 redo log 的位置。checkpoint lsn 是 InnoDB 认为“此前所有页变更已刷盘”的边界点。
启动时扫描日志必须从 checkpoint lsn 开始，否则会重放已持久化的操作，导致数据重复或错乱。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- lsn 数值很大（如
30277069237949）是正常的，InnoDB lsn 是 64 位整数，日常运行几周就会到千亿级 - 如果 lsn 跳变异常（比如倒退、突降），可能是日志文件被截断或覆盖，需检查
ib_logfile0/ib_logfile1是否被手动删除或损坏 - 该行后面若接
Doing recovery: scanned up to log sequence number YYY，且 YYY 远小于 XXX，说明日志不完整 —— 常见于磁盘满、I/O 错误或日志文件被清空
什么时候要警惕这行日志？
单看这行无害，但若它反复出现在失败循环中（比如启动 → 打印这行 → 崩溃 → 重启再打这行），说明 recovery 卡在某个环节，背后有更深层问题：
- 硬盘 I/O 错误：日志里同时出现
Operating system error number 5（Input/output error）或Write to file ... failed - InnoDB 表空间损坏：紧跟其后出现
InnoDB: Database page corruption on disk或Assertion failure in file fsp0fsp.c line 1593 - 内存或配置不足：buffer pool 太小导致 recovery 过程 OOM，进程被系统 kill，日志停在 “scanned up to” 就中断
- redolog 文件缺失或大小不匹配：
ib_logfile0和ib_logfile1被删过或 chmod 为只读，InnoDB 无法打开它们，scan 会失败并退出
如何快速验证 recovery 是否真完成？
不能只盯这一行，要看它之后有没有出现明确的成功信号：
- 成功标志：
InnoDB: Started; log sequence number XXX（注意是Started;，不是Starting...） - 失败标志：没有这句，而是紧接着
mysqld: ready for connections缺失，或者进程直接 segfault / abort - 最简验证法：启动后立刻执行
mysql -e "SELECT 1"，能返回结果才算 recovery 真结束 - 如果卡在 “Progress in percents: 0 1 2 …” 且长时间不动（尤其卡在 0 或 100），大概率是某张表的 .ibd 文件损坏，需要
innodb_force_recovery干预
实际运维中，这行日志就像汽车启动时的“引擎轰鸣”——声音大不代表出问题，但要是轰了十秒还没着火，就得查油路、火花塞和电瓶了。
