SQL事务日志通过WAL机制保障持久性：COMMIT前日志必须落盘，崩溃后靠redo/undo恢复；依赖直接I/O、写屏障等确保持久，配置如synchronous_commit或延迟持久性可权衡性能与可靠性。
SQL 事务日志通过“先写日志，后写数据”（Write-Ahead Logging, WAL）机制保证持久性：只要事务提交成功，对应的日志记录一定已安全写入磁盘，即使系统崩溃，重启后也能依据日志恢复已提交的修改。
事务提交前必须完成日志落盘
当执行 COMMIT 时，数据库不会直接把缓冲区中的数据页刷到磁盘，而是确保该事务所有修改对应的日志记录（包含操作类型、表、行、旧值/新值等）已同步写入物理日志文件（如 SQL Server 的 .ldf，PostgreSQL 的 WAL 文件）。这个过程由日志写入器（log writer）严格控制，并等待操作系统返回“写入完成”确认（通常调用 fsync 或类似同步接口）。
- 未完成日志落盘，COMMIT 就不会返回成功，客户端收不到“事务已提交”的响应
- 数据库可配置日志写入策略（如 SQL Server 的 FULL vs BULK_LOGGED 恢复模式），但FULL 模式下所有 DML 都完整记日志，是持久性的基础保障
崩溃恢复依赖日志重放（Redo）
系统意外中断后，重启时数据库自动进入恢复阶段。此时它会扫描事务日志：
- 找到最后检查点（checkpoint）位置，从该处开始读取后续日志
- 对所有已提交但尚未写入数据页的事务，重新执行其日志记录（redo phase），把变更应用到数据页
- 对未提交或已回滚的事务，按日志反向操作（undo phase），撤销其影响
这一机制确保：只要日志完整，已提交事务的效果就永远不会丢失——这正是持久性（Durability）的定义。
日志文件本身需具备可靠性
日志的持久性不能只靠逻辑流程，还依赖底层存储保障：
- 避免缓存干扰：数据库通常绕过文件系统缓存，使用直接 I/O（O_DIRECT）或强制 fsync，防止日志滞留在内存中
- 避免硬件乱序：高端存储支持写屏障（write barrier）或启用电池保护的写缓存（BBWC），确保日志写入顺序不被磁盘控制器打乱
- 日志归档与镜像：生产环境中常开启日志备份（如 SQL Server 的日志传送、PostgreSQL 的 WAL 归档），进一步防范磁盘故障导致的日志丢失
用户可控的关键配置项
DBA 可通过以下设置直接影响持久性行为：
- 延迟日志写入（Delayed Durability）：SQL Server 允许设为 FORCED（强持久）或 ALLOWED（异步写日志，牺牲部分持久性换性能）；PostgreSQL 中对应 synchronous_commit = off
- 日志文件位置：将 .ldf 或 pg_wal 放在独立、高可靠的磁盘上，避免与数据文件争抢 I/O 或共用故障域
- 最小日志量：某些操作（如 SELECT INTO、索引重建）在简单恢复模式下可能最小化日志，但这类操作不满足 ACID 持久性要求，应避免在关键事务中使用
