Insert Buffer是专为非唯一辅助索引设计的B+树结构，通过延迟合并实现随机写聚合，仅在索引页加载到缓冲池或后台线程触发时执行合并，从而减少磁盘I/O。
插入缓冲本质是“延迟+聚合”的内存暂存机制
插入缓冲（Insert Buffer）不是简单缓存，而是专为非唯一辅助索引设计的、带合并逻辑的B+树结构——它本身就存于共享表空间中，和数据页一样物理存在。当插入一条记录导致某个辅助索引页不在缓冲池（Buffer Pool）中时，InnoDB不会立即去磁盘读取该页，而是把这次修改（如插入一个(name='alice', id=1001)）以“待合并项”形式插入到Insert Buffer这棵B+树里，键值按(space_id, page_no, counter)组织。这意味着：同一索引页的多次插入，会被路由到同一个Insert Buffer节点下，天然具备聚合条件。
合并动作由后台线程触发，且只在页被加载时才真正执行
关键点在于：Insert Buffer中的内容不会主动刷盘，也不会单独写入磁盘。它的合并发生在两个时机：
- 当
master thread周期性唤醒（默认每秒一次）时，尝试合并部分Insert Buffer项到对应索引页（前提是该页此时已在Buffer Pool中） - 更常见的是——当某条查询首次访问该辅助索引页（例如
SELECT * FROM t WHERE name = 'bob'），InnoDB必须把该页从磁盘读入Buffer Pool；此时会**立刻触发合并**：把所有针对这个page_no的Insert Buffer记录，一次性应用到刚载入的页上，再标记为脏页
这种“懒合并”机制让原本分散在不同时刻、不同位置的随机写，被压缩成一次内存内的批量操作，彻底规避了多次磁盘寻道。
为什么只对非唯一辅助索引生效？
这是设计上的硬约束，直接关系到能否安全跳过一致性检查：
-
UNIQUE索引插入前必须校验唯一性，而校验需读取目标页——这就又回到随机I/O，Insert Buffer失去意义 - 主键（聚集索引）本身是顺序插入的，无需优化随机写
- 只有非唯一辅助索引，才既存在大量随机写场景，又允许“先记账、后核对”，因为重复值本身合法，无需即时验证
所以如果你看到INSERT没走Insert Buffer，先检查索引定义：SHOW INDEX FROM t，确认是否满足“非唯一 + 非主键”两个条件。
Change Buffer 是 Insert Buffer 的超集，但行为逻辑一致
MySQL 5.5+ 引入的Change Buffer把适用范围扩展到了UPDATE、DELETE甚至PURGE，但它底层仍是同一套机制：对非唯一辅助索引页的变更，若页未在缓冲池中，就暂存在Change Buffer（逻辑上兼容并扩展了Insert Buffer）。监控时注意：SHOW ENGINE INNODB STATUS里的Insert buffer and adaptive hash index段显示的是整个Change Buffer状态，不是旧版纯插入缓冲。
真正容易被忽略的是：当业务大量写入后突然执行全表扫描或大范围WHERE name = ?查询时，会集中触发大批量Change Buffer合并，造成短暂I/O尖峰和缓冲池压力——这不是bug，是机制使然。
