唯一索引无法用change_buffer加速插入，因其必须在写入时立即校验唯一性，强制同步读取索引页，绕过change_buffer机制，导致随机i/o上升、buffer pool命中率下降。
唯一索引无法用 change_buffer 加速插入，这是 MySQL 的硬限制，不是配置没调对。
为什么 change_buffer 对唯一索引完全无效
change_buffer 的设计目标是缓存「非唯一二级索引」的变更操作（INSERT/UPDATE/DELETE），等后续读取页时再合并写入。但唯一索引必须在写入时立刻检查重复值——否则就可能破坏唯一性约束。所以 MySQL 在插入时必须同步定位并访问索引页，跳过 change_buffer 路径。
- 执行
INSERT INTO t (id, name) VALUES (1, 'a')时，如果name上有唯一索引，MySQL 必须立刻读取对应 B+ 树页，确认 'a' 是否已存在 - 这个“立刻读页”动作绕过了 change_buffer，也就失去了延迟写入、批量合并的优化机会
-
SHOW ENGINE INNODB STATUS中的Buffer pool hit rate会明显下降，Pages read ahead可能激增，说明随机 I/O 上升
唯一索引插入变慢的典型表现与归因
你看到 INSERT 变慢，大概率不是因为 change_buffer 没开，而是它根本开不了——得换思路。
- 错误现象：
SHOW PROCESSLIST显示大量线程卡在updating或statistics状态；innodb_row_lock_waits持续上升；Handler_read_rnd值异常高 - 真正瓶颈：唯一索引字段值分布不均（比如大量插入相同前缀的字符串），导致 B+ 树局部竞争激烈
- 更隐蔽的问题：唯一索引列类型是
VARCHAR(2000)，每次比较都要全字段比对，CPU 开销大；或用了函数索引如LOWER(name)，每次 INSERT 都要计算函数值
能实际起效的替代方案
既然 change_buffer 不可用，就得从唯一性校验本身和写入路径上下手。
- 把唯一约束从数据库层移到应用层做预检（仅限业务可容忍极低概率冲突的场景），例如 Redis + Bloom Filter 做前置去重
- 改用
INSERT IGNORE或ON DUPLICATE KEY UPDATE替代先查后插，避免两次索引查找（一次 SELECT + 一次 INSERT） - 对长文本唯一字段，改用哈希值索引：增加
name_hash CHAR(32) AS (MD5(name)) STORED，再在该列建唯一索引，查询时用WHERE name_hash = MD5(?) - 确认唯一索引是否真有必要：比如邮箱字段加了唯一索引，但业务其实允许少量重复（如测试账号），那就删掉
别碰的“伪优化”操作
有些做法看似合理，实则危险或无效。
- 设
innodb_change_buffer_max_size = 50：对唯一索引完全无影响，还可能挤占 buffer pool 给其他有效缓存的空间 - 用
ALTER TABLE t DISABLE KEYS：对唯一索引无效，执行后会被 MySQL 忽略，且可能触发警告 - 试图用
SET SESSION sort_buffer_size = 2M加速唯一性检查：该参数只影响 ORDER BY / GROUP BY，跟唯一索引校验无关
唯一索引的性能代价是刚性的，它不像普通索引那样能靠缓冲区或批量合并来掩盖。最常被忽略的一点是：**唯一性校验的开销，80% 来自索引页加载的随机 I/O，而不是 CPU 计算**——所以 SSD 替代 HDD、提升 innodb_buffer_pool_size 才是最直接有效的手段。
