SQL数据库Buffer Flush策略通过检查点批量刷盘、WAL日志强制刷盘、缓冲区压力驱逐刷盘及后台定时刷盘四类机制协同实现性能与安全平衡。
SQL数据库的Buffer Flush策略，核心在于平衡性能与数据安全性——缓存中的修改（脏页）不能一直不写入磁盘，也不能每次修改都立即刷盘。刷盘时机不是固定不变的，而是由多种机制协同触发的。
检查点（Checkpoint）驱动的批量刷盘
检查点是数据库保证崩溃恢复效率的关键机制。当触发检查点时，系统会将某个时间点之前所有已提交事务产生的脏页批量刷入磁盘。这避免了恢复时需要重做大量日志。
- 主动检查点：DBA手动执行 CHECKPOINT 命令，或配置自动检查点间隔（如 SQL Server 的 recovery interval）
- 被动检查点：日志空间不足、数据库关闭、备份开始等事件也会强制触发检查点
- 注意：检查点只刷脏数据页，不刷日志页；日志刷盘由 Write-Ahead Logging（WAL）独立控制
事务提交时的日志强制刷盘（WAL保障）
根据 WAL 原则，事务的 REDO 日志必须在事务成功提交前落盘，但对应的数据页（
脏页）可以延迟刷盘。这意味着：
-
Commit 不等于数据落盘：COMMIT 返回成功，仅表示日志已写入磁盘，数据页仍可能留在 buffer pool 中
- 日志刷盘方式可配置：如 PostgreSQL 的 sync_commit = on/off，SQL Server 的 full recovery model + log backups 会影响日志截断和刷盘节奏
- 异步日志写入（如 MySQL 的 innodb_flush_log_at_trx_commit = 2）会提升吞吐，但牺牲掉断电时最多1秒日志丢失的风险
缓冲区压力触发的主动驱逐刷盘
当 buffer pool 空间紧张（例如新页需加载而无空闲帧），数据库会通过 LRU 或改进型算法选择脏页进行淘汰，此时必须先将其刷盘，否则会丢失未持久化的修改。
- SQL Server 使用 Lazy Writer 后台线程定期扫描 buffer pool，释放干净页、刷出脏页
- MySQL InnoDB 依赖 Page Cleaner 线程，在满足条件（如 buf_get_total_pages() 超过 innodb_buffer_pool_size × 75%）时异步刷脏页
- 这种刷盘不可预测、非均匀，但能防止内存耗尽导致的阻塞
后台定时刷盘与配置参数联动
多数数据库提供周期性刷盘机制，作为检查点和压力刷盘的补充，使脏页更平滑落地，降低峰值 I/O 冲击。
- PostgreSQL 的 bgwriter_delay 控制后台写进程休眠间隔，默认200ms；bgwriter_lru_maxpages 限制每次刷页数
- SQL Server 的 recovery interval（单位分钟）影响检查点频率，间接调控刷盘节奏
- MySQL 的 innodb_io_capacity 和 innodb_io_capacity_max 指导 Page Cleaner 的刷盘速率，适配 SSD/HDD 性能差异
实际刷盘行为是上述机制叠加的结果：一次脏页可能因检查点被刷、也可能因 buffer 不足被驱逐、还可能被后台线程顺带处理。理解各策略的触发条件和优先级，才能合理调优 durability、performance 和 resource usage 之间的关系。
脏页）可以延迟刷盘。这意味着：