insert变慢主因是索引维护与锁竞争失控：两千万行时b+树深度增至4层，每插入需多次磁盘随机写；低基数索引拖累写入，间隙锁/临键锁引发高并发排队，buffer pool命中率恶化加剧i/o瓶颈。
写入变慢不是“数据多”本身导致的，而是索引维护和锁竞争在两千万量级开始失控
当单表突破两千万行，INSERT/UPDATE耗时明显拉长，常见现象是：原本 5ms 的插入变成 80ms 以上，批量写入吞吐量下降 50%+。这不是 MySQL 突然“变笨”，而是底层机制在数据规模放大后暴露瓶颈。
InnoDB 聚簇索引页分裂 + B+树深度增加，让每次写入成本翻倍
主键如果是自增 BIGINT，写入本应顺序追加；但一旦有二级索引（尤其是非唯一、低选择性索引），每条记录插入都要更新所有相关索引树。两千万行时，B+树高度通常达 4 层，而百万级常为 2–3 层——这意味着一次 INSERT 可能触发 4 次磁盘随机写（每个层级一次页加载+修改）。
- 高频写入字段（如
status、updated_at）若建了单独索引，会显著加剧页分裂和缓冲池压力 -
innodb_page_size=16K下，单页能存的索引项有限；数据越密，分裂越频繁，产生大量碎片页 - 用
SHOW INDEX FROM table_name查看Cardinality，若某索引基数远低于总行数（比如user_type只有 5 个值），它几乎不加速查询，却全程拖慢写入
行锁升级为间隙锁/临键锁，高并发写入排队成常态
两千万行表上，WHERE 条件若没走索引或走的是低效索引，InnoDB 会扩大锁定范围。更隐蔽的是：即使走了索引，范围更新（如 UPDATE ... WHERE create_time > '2025-01-01'）也会触发大量临键锁（Next-Key Lock），阻塞其他事务对相邻值的写入。
- 执行
SELECT * FROM information_schema.INNODB_TRX常能看到trx_state = 'LOCK WAIT'的长列表 - 用
SHOW ENGINE INNODB STATUS\G查---TRANSACTION段，能定位具体被哪个锁阻塞 - 避免在写多场景下对非主键字段做范围更新；优先用主键 or 主键范围分批更新
Buffer Pool 不再“够用”，磁盘 I/O 成为写入瓶颈
假设 innodb_buffer_pool_size 设为 16GB，而两千万行订单表（含索引）实际占用 35GB，那么约 55% 的页操作需落到磁盘。尤其当写入触发 change buffer 合并（如二级索引页不在内存中），会引发后台线程密集刷脏页，进一步抢占 I/O 资源。
- 监控
Innodb_buffer_pool_reads（每秒磁盘读）和Innodb_buffer_pool_read_requests（每秒逻辑读），比值持续 > 0.01 就说明命中率恶化 - 不要盲目调大
innodb_buffer_pool_size，需确保系统剩余内存足够 OS 缓存和 MySQL 连接线程开销 - SSD 可缓解但不能根治——真正卡住的是锁等待和索引维护逻辑，不是单纯“硬盘慢”
最容易被忽略的一点：写入性能断崖往往不是从两千万整数点开始，而是当某张表的二级索引数量 ≥ 5 个、且其中 ≥ 2 个基数 slow log 报告写入慢才查，先跑一遍 SELECT table_name, index_name, cardinality, seq_in_index FROM information_schema.STATISTICS WHERE table_schema = 'db' AND table_name = 't' ORDER BY cardinality ASC;
