这是一个非常经典的数据库内核设计问题。简单直接的答案是：唯一索引的修改操作需要"立即"检查唯一性约束，而这一检查过程必须读取索引页到内存中，这本身就破坏了Change Buffer"延迟读取磁盘页"的核心优化前提。
下面我们来详细拆解原因。
1. 核心矛盾：唯一性校验需要实时数据
Change Buffer的核心思想是：当修改一个非唯一二级索引页时，如果该页不在内存（Buffer Pool）中，就先记下这个"更改操作"，而不是立刻从磁盘读取该页。等以后该页被其他查询读到内存时，再批量应用这些更改。
这个机制能生效，是建立在一个重要前提上的：这个二级索引允许重复值。因此，数据库可以"信任"这个修改操作（插入、更新、删除）在没有立即看到实际页面的情况下，大概率不会违反索引的约束。
但对于唯一索引，情况完全不同：
- 当你插入一行
(user_id=100)到唯一二级索引时，InnoDB 必须 立刻知道索引中是否已经存在user_id=100这条记录。 - 为了验证唯一性，数据库引擎不得不同步地、立即地从磁盘读取该索引的相应叶子节点页，加载到Buffer Pool中，然后扫描该页（可能还有前后页）以确认没有重复键。
- 一旦这个索引页被强制读入内存，Change Buffer 就失去了用武之地------因为你已经在内存里拿到了最新的页面，完全可以直接在这个页面上应用修改，何必再去写一个"待办事项"呢？
2. 逻辑自洽：如果有Change Buffer会怎样？
假设为唯一索引启用了Change Buffer，我们来模拟一个并发场景：
- 事务A：插入
(user_id=100)，该索引页不在内存。按照Change Buffer逻辑，把"插入"操作记录到Change Buffer，事务提交。 - 事务B：紧接着插入
(user_id=100)，同样，索引页可能仍不在内存。它也去Change Buffer里记录一个"插入"操作。 - 问题来了：事务B如何知道刚刚事务A已经插入了一个
100？它无法知道。因为Change Buffer中的修改还没有合并到实际的数据页上，也没有全局的"快照"能快速检查唯一性。事务B会"认为"还没有100，也成功记录了自己的插入。
最终，当这两个"插入"操作合并到索引页时，就会违反唯一性约束，但此时已经来不及报错了。
结论：要保证唯一性，必须在修改发生的 那一刻 看到真实数据页的最新状态。这强制要求了同步读页**，从而完全绕过了Change Buffer。**
3. 性能与代价的权衡
从设计目标来看，Change Buffer 针对的是"非唯一二级索引"的随机写优化。
- 针对场景：大量插入、更新操作，尤其是数据无法按索引顺序写入时（比如UUID作为主键的二级索引）。这些操作会导致大量的随机I/O，Change Buffer 将这些随机I/O合并、推迟，变成后续的异步顺序I/O。
- 唯一索引的成本：唯一索引为了实现约束，每次DML操作都需要至少一次额外的索引页随机读取（用于查重）。这个随机读取的代价，在高并发下常常比非唯一索引使用Change Buffer的代价要大得多。InnoDB的设计者认为，为了保证数据完整性，这个代价是必须支付的，无法被优化掉。
总结对比
| 特性 | 非唯一二级索引 | 唯一索引 |
|---|---|---|
| 是否需要实时查重 | 不需要 | 需要 |
| 修改时能否延迟读页 | 可以 | 不可以 (必须立即读页以验证唯一性) |
| Change Buffer是否生效 | 生效 | 不生效 |
| 典型优化场景 | 大量随机插入、批量加载 | 需保证字段值全局唯一的业务 (如用户ID、订单号) |
补充说明：Change Buffer 的生效范围
严格来说，Change Buffer 主要优化的是 INSERT、UPDATE、DELETE 操作对非唯一二级索引 页的修改。对于主键索引（聚簇索引） ，Change Buffer 也不生效，因为主键必须唯一且直接定位数据行，读取主键索引页是查找数据的必要步骤，无法延迟。
所以，当你发现数据库有大量的唯一索引，并且写负载很高时，不应该期望Change Buffer能帮忙。此时的优化方向通常是：检查业务上是否真的需要那么强的唯一性约束（能否用应用层逻辑或唯一索引降级为非唯一？），或者考虑分库分表、使用更好的硬件（如NVMe SSD）来降低随机读的延迟。