日志一致性边界由最后成功落盘的commit/abort日志记录决定，WAL确保日志先于数据页持久化，检查点仅压缩恢复扫描范围，截断日志会破坏边界，各引擎实现细节不同但本质一致。
SQL数据库事务日志的一致性，直接决定崩溃后能否准确还原到某个已提交事务的完整状态。核心在于：日志必须按逻辑顺序记录所有数据变更（包括begin、modify、commit/abort），且每个日志记录在写入磁盘前，其对应的缓冲区页修改不能先于日志落盘（WAL原则）。崩溃恢复时，系统仅依赖日志中已持久化的部分重放（Redo）和回滚（Undo），因此“日志一致性边界”本质上是日志记录的原子性、持久性与检查点协同作用的结果。
WAL机制如何划定一致性边界
Write-Ahead Logging 要求：任何数据页的修改写入数据文件之前，其对应的日志记录必须已写入日志文件并刷盘（fsync）。这意味着：
- 日志文件中每个Lsn（Log Sequence Number）对应一个不可分割的变更单元；
- 若某条commit日志记录已落盘，但其修改的数据页尚未写入数据文件，崩溃后可通过该日志重放补全；
- 若commit日志未落盘，即使数据页已刷盘，该事务也视为未提交，恢复时会被Undo清除；
- 因此，日志文件的“最新有效commit Lsn”构成恢复起点——即最后一个被完整写入并确认的事务边界。
检查点（Checkpoint）对恢复范围的压缩作用
检查点不是一致性断点，而是性能优化手段：它将内存中已提交事务修改的脏页批量刷入数据文件，并在日志中标记一个“检查点记录”。此后崩溃恢复只需从该检查点记录开始扫描日志，而非从日志起始位置。关键点在于：
- 检查点本身不保证其时刻所有已提交事务都已完成刷盘，只保证该时刻之前的所有脏页最终会被刷完；
- 恢复时需结合检查点记录中的“最早活动事务ID”和“最近一次刷盘的Lsn”，确定Redo起点和Undo范围；
- 真正的一致性边界仍由日志中最后一条成功落盘的commit/abort记录决定，检查点只是缩小搜索窗口。
崩溃时刻的日志截断风险与防护
日志文件若被意外截断（如存储故障、人为清空、归档失败），会导致部分已提交事务日志丢失，从而破坏一致性边界。典型场景包括：
- 日志备份失败后未及时告警，后续日志覆盖旧内容；
- 使用简单恢复模式时，checkpoint后日志被自动截断，但若此时发生崩溃且无备份，只能恢复到上一个checkpoint；
- 主从同步中，从库日志应用延迟导致其本地日志边界滞后于主库，failover后可能丢失最后几笔事务。
防范措施包括启用强制日志归档、设置日志保留策略、监控log_reuse_wait_desc状态、避免在生产环境手动截断日志。
不同SQL引擎对边界处理的细微差异
SQL Server、PostgreSQL、MySQL（InnoDB）均遵循WAL，但在边界判定逻辑上有区别：
- SQL Server 使用“最小恢复Lsn”（MinLSN）标识必须保留的日志起点，由活动事务和检查点共同决定；
- PostgreSQL 的checkpoint记录包含redo LSN 和 nextXid，恢复从该redo LS
N开始，结合clog判断事务状态；
- InnoDB 的checkpoint由lsn值标记，但恢复时还需解析undo log段头页确认活跃事务，Undo日志本身也受WAL保护。
这些差异不影响一致性本质，但影响DBA排查恢复失败原因时的关注重点。
N开始，结合clog判断事务状态；