INSERT变慢可能因change buffer未生效：它仅对非唯一二级索引且对应页不在buffer pool时起作用；若索引唯一、页已缓存或配置不当（如innodb_change_buffering非all），则失效。
为什么INSERT变慢，可能不是SQL问题而是insert buffer没起效
InnoDB的insert buffer（现称change buffer）专为非唯一二级索引的写入优化设计——它把随机IO转为顺序IO。但很多人误以为只要建了索引它就自动加速，其实默认只对INSERT、UPDATE、DELETE中涉及“非唯一二级索引页不在缓冲池内”的场景生效。如果索引是主键或唯一索引，或者目标页已在内存里，change buffer直接跳过，不参与写入流程。
常见错误现象：SHOW ENGINE INNODB STATUS\G里看到Insert buffer and adaptive hash index区块中merged operations极低，甚至长期为0；同时ibuf size始终很小（比如1或2），说明它基本没被用起来。
- 确认是否满足触发条件：目标索引必须是非唯一二级索引，且对应的数据页当前不在
buffer pool中（即冷数据写入） - 检查
innodb_change_buffering值是否为all（默认值），若设成none或inserts以外的子集，会限制合并范围 - 避免在写入前手动
SELECT相关索引字段——这会把索引页提前加载进buffer pool，让change buffer失效
如何验证change buffer是否真在工作
不能只看配置开了没，得看运行时指标。最直接的方式是查INFORMATION_SCHEMA.INNODB_METRICS中的聚合统计：
SELECT NAME, COMMENT, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'change_buffer%';
重点关注以下三项：
-
change_buffer_merge_operations：实际完成的合并次数，持续增长才说明它在干活 -
change_buffer_page_written：写入change buffer的页面数，批量插入时应明显上升 -
change_buffer_pages_merged：后台线程合并进主B+树的页数，和merge_operations应大致匹配
如果page_written高但pages_merged长期停滞，可能是innodb_io_capacity设得太低，导致后台刷脏/合并节奏太慢；也可能是innodb_adaptive_flushing关闭，无法动态调节刷盘压力。
哪些配置直接影响change buffer效果
change buffer不是独立内存池，它占用的是innodb_buffer_pool_size的一部分（上限默认为25%）。它的行为受多个参数协同控制，调错一个就可能让它“静音”：
-
innodb_change_buffer_max_size：控制最大占比，默认25，可调至50（如大量写入非唯一索引的场景），但别超75，否则挤压热数据缓存空间 -
innodb_change_buffering：决定哪些操作启用，生产建议保持all；若只做批量导入且后续不立刻查，可临时设为inserts减少合并开销 -
innodb_io_capacity和innodb_io_capacity_max：这两个值必须合理，否则后台合并线程跟不上写入节奏。SATA SSD建议200/2000，NVMe建议2000/4000，且务必确保innodb_adaptive_flushing = ON -
innodb_buffer_pool_size本身要够大：如果缓冲池常年free pages = 0且dirty_ratio > 75%，change buffer连落脚的地方都没有
批量插入时change buffer的实战取舍
在明确知道后续不会立即查询新数据的前提下，可以主动“放大”change buffer的作用窗口，换取更高吞吐：
- 插入前执行
SET SESSION innodb_change_buffering = 'inserts'，禁用delete和update类合并，减少后台干扰 - 配合
DISABLE KEYS（仅MyISAM有效）不适用，但InnoDB下可考虑先删掉非关键的非唯一二级索引，插入完成后再重建——这比依赖change buffer更彻底 - 真正追求极致速度时，
LOAD DATA INFILE仍是首选：它绕过SQL解析层，直接走存储引擎接口，change buffer机制会自动适配，且不受max_allowed_packet限制 - ORM用户要注意：Hibernate/JPA的
saveAll()默认仍发多条单行INSERT，需显式启用批量模式并确认驱动支持rewriteBatchedStatements=true
真正容易被忽略的点是：change buffer的收益高度依赖“写后不立即读”的业务模式。一旦插入后马上按二级索引字段SELECT，InnoDB必须立刻合并对应页，反而增加延迟——这时候不如关掉它，让写入路径更确定。
