SQL数据库崩溃后能自动恢复，依赖WAL日志与检查点机制：先分析日志定位活跃/已提交事务，再重做已提交操作，最后回滚未完成事务。
SQL 数据库崩溃后能自动恢复数据，核心依赖于事务日志（WAL）和检查点机制，整个流程不是“重放所有操作”，而是精准定位未完成事务并回滚、已提交但未写入数据文件的事务则重做。
崩溃发生时的状态保存
数据库运行中会持续写入事务日志（如 PostgreSQL 的 WAL、SQL Server 的 LDF、MySQL InnoDB 的 redo log），每条修改操作在写入数据页前先记日志。同时定期触发检查点（checkpoint），将内存中已提交的脏页刷到磁盘，并记录当前日志位置。崩溃时，内存中的数据页丢失，但日志文件通常完整保留在磁盘上。
启动时的恢复阶段划分
数据库服务重启后，自动进入恢复模式，分为三个逻辑阶段：
- 分析阶段（Analysis）：扫描日志，确定最近一次检查点的位置，识别出哪些事务在崩溃时处于活跃（未提交）、哪些已提交但对应的数据页可能尚未刷盘。
- 重做阶段（Redo / Roll-forward）：从检查点开始，重放所有已提交事务的日志记录，确保所有已确认的修改都反映到数据文件中（即使当时还没写盘）。
- 回滚阶段（Undo / Rollback）：对分析阶段发现的未完成事务（比如崩溃时正执行到一半的 UPDATE），利用日志中的 undo 信息撤销其已做的修改，保证原子性。
关键保障机制说明
恢复可靠性的基础是日志的持久化策略：
- 默认情况下，事务提交（COMMIT）必须等待对应日志记录落盘（fsync），才向客户端返回成功——这是“WAL 先写”原则。
- 检查点不能太频繁（避免 I/O 压力），也不能太久（否则恢复需重放大量日志）。多数系统支持配置间隔或脏页比例触发。
- 部分数据库（如 PostgreSQL）允许设置 synchronous_commit = off 来提升性能，但会牺牲崩溃时少量已提交事务的持久性。
用户可观察与干预的点
恢复过程对用户透明，但可通过以下方式了解或影响行为：
- 查看错误日志：启动时通常会打印 “Database system was interrupted; will perform recovery” 类提示，并显示重做/回滚的记录数。
- 监控恢复进度：PostgreSQL 可查 pg_stat_progress_recovery 视图；SQL Server 可通过 ERRORLOG 或 DMV sys.dm_exec_requests 查看 ROLLFORWARD 状态。
- 手动触发检查点：紧急情况下可执行 CHECKPOINT（PostgreSQL/SQL Server）或 FLUSH ENGINE LOGS（MySQL），缩短后续恢复时间。
