UPDATE语句执行时，InnoDB先将目标行所在16KB数据页加载至Buffer Pool（若未命中则从磁盘读取），在内存中修改并写入undo log，标记该页为脏页；刷盘异步延迟，由脏页占比超75%、Redo Log空间不足或checkpoint机制触发。
MySQL执行UPDATE语句时，Buffer Pool不是被动缓存，而是主动参与修改的核心内存区域——所有数据变更都先发生在Buffer Pool中，而不是直接写磁盘。
UPDATE执行时Buffer Pool中发生了什么
当UPDATE语句命中某行记录，InnoDB会按需将该行所在的数据页（16KB）加载进Buffer Pool（若尚未在内存中）。随后所有修改都在该页的内存副本上进行，原值被写入undo log，新值覆盖旧值，该页随即被标记为“脏页”（Dirty Page）。
- 即使只改一个字段，整页都会被加载并标记为脏页
- 如果页已存在于Buffer Pool，跳过磁盘IO，直接加锁+修改，这是性能关键点
- 修改不触发立即刷盘，也不阻塞事务提交——刷盘是异步、延迟、受控的
脏页何时刷回磁盘：由三个条件共同驱动
脏页不会等事务提交就落盘，也不会等Buffer Pool满才刷，而是由后台线程依据以下条件综合判断：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 当脏页占比超过
innodb_max_dirty_pages_pct_lwm（默认0，即不启用低水位预刷）时，可能提前启动轻量刷新 - 当脏页占比超过
innodb_max_dirty_pages_pct（默认75%）时，进入“勤快刷新模式”，刷盘频率和并发度显著提升 - Redo Log空间即将用尽（需要循环复用旧日志文件）时，强制触发
sharp checkpoint，把所有涉及该Log段的脏页同步刷盘——这容易引发IO尖峰
Checkpoint机制如何影响刷盘节奏
Checkpoint不是一次性清空所有脏页，而是持续推进一个“检查点LSN”，表示“这个LSN之前的所有修改，其对应脏页已确保刷盘或至少能通过Redo Log恢复”。它决定了：
- 崩溃恢复起点：重启后只需重放Checkpoint之后的Redo Log
- Redo Log可复用范围：只有Checkpoint之前的Log段才能被覆盖
- 刷盘压力分布：平滑Checkpoint（
innodb_adaptive_flushing=ON）会根据当前IO负载动态调节刷盘速率；而sharp checkpoint是硬性、批量、不可控的
真正容易被忽略的是：innodb_max_dirty_pages_pct_lwm默认为0，意味着InnoDB几乎不主动预刷脏页，长期高负载下脏页比例会稳定贴近75%，一旦遇到Redo Log切换或大事务提交，sharp checkpoint极易被触发——这不是配置问题，而是设计默认行为。调优时应优先确认该参数是否仍为0，并结合监控Innodb_buffer_pool_pages_dirty与Innodb_log_waits来判断刷盘是否已成为瓶颈。
