mysql执行insert变慢主因是索引维护开销：每行插入需同步更新主键b+树、每个二级索引b+树、redo log和binlog，索引越多随机i/o与页分裂越频繁，尤其uuid主键加剧分裂，导致cpu和i/o瓶颈。
索引维护变慢不是“MySQL变老了”，而是每插一行，InnoDB 就得同步更新主键 B+ 树 + 所有二级索引 B+ 树 + redo log + binlog —— 索引越多，写入路径越长，随机 I/O 和页分裂越频繁。
为什么每多一个索引，INSERT 就明显更卡？
插入一行数据，InnoDB 实际执行的是多次独立的 B+ 树写入操作：
- 主键（聚簇索引）B+ 树写入 1 次
- 每个二级索引对应一棵 B+ 树，各写入 1 次 → 5 个二级索引 = 额外 5 次树定位、页查找、可能分裂
- 唯一索引（
UNIQUE INDEX）还强制触发一次存在性校验（查索引树），无法被change_buffer缓存 - 外键约束字段也会额外查关联表，同样绕过缓冲
这些操作不是顺序追加，而是随机定位 + 页内插入 + 满则分裂。尤其当主键是 UUID 或倒序时间戳时，分裂频率激增，CPU 和 I/O 都被锁死。
INSERT 越插越慢，真是因为数据量大吗？
不是。实测显示：同一张表插入 10 万行，前 1 万行平均耗时 0.8ms/行，后 1 万行涨到 4.2ms/行 —— 差异主因是 B+ 树深度增加、页碎片增多、缓冲池局部性下降。
- 页分裂后留下空洞，后续插入更易触发新分裂
- 索引页在磁盘上物理不连续，
SELECT可能还没变慢，但INSERT已开始“找页”困难 -
INFORMATION_SCHEMA.INNODB_BUFFER_PAGE中若大量索引页page_type = 'INDEX'且page_state = 'FREED'或利用率，说明碎片已严重
ALTER TABLE DISABLE KEYS 为什么对 InnoDB 基本无效？
这个命令只对 MyISAM 表真正生效；InnoDB 自 5.7 起虽支持语法，但仅在 LOAD DATA INFILE 场景下部分绕过索引更新逻辑，普通 INSERT 语句完全不响应。
- 执行
ALTER TABLE t DISABLE KEYS后查SHOW INDEX FROM t，状态仍是enabled - 真正有效的做法是：导入前
DROP INDEX idx_name ON t（避开唯一索引），导入完再CREATE INDEX - 注意：
DROP INDEX会锁表，需评估业务窗口；主键和唯一索引绝不能删，否则重复数据会静默跳过或报Duplicate entry
唯一索引和 change_buffer 之间根本没商量
change_buffer（原 insert buffer）只缓存「非唯一、非聚集」的二级索引变更。一旦你建了 UNIQUE(name)，所有对该字段的插入都必须实时走索引树，无法延迟合并。
- 这意味着：哪怕其他 4 个索引都靠 change_buffer 缓冲，只要有一个唯一索引，整条插入链路就卡在同步校验上
-
SHOW ENGINE INNODB STATUS的INSERT BUFFER AND ADAPTIVE HASH INDEX段里，如果merged operations极低但inserts很高，大概率就是唯一索引拖了后腿 - 临时方案：
SET unique_checks = 0（导入前确保数据无重复），导入完立刻SET unique_checks = 1并手动验证
最常被忽略的一点：索引优化不是“选哪个参数调一下”，而是要结合主键设计（自增 vs UUID）、数据顺序（是否 ORDER BY id）、事务粒度（BEGIN 包多少行）一起动刀——单改 innodb_flush_log_at_trx_commit 只能救一半。
