InnoDB高并发写入卡顿主因是锁争用与日志刷盘的串行化瓶颈：间隙锁扩大锁范围，innodb_flush_log_at_trx_commit=1强制每次提交fsync，I/O成性能瓶颈；需协同调优锁策略、日志参数、批量大小及索引设计。
为什么InnoDB在高并发写入时容易卡住
InnoDB不是“天生快”，它在高并发写入下卡顿，主因是锁争用和日志刷盘这两个硬性串行环节。比如多个事务同时执行 UPDATE t SET status = 'done' WHERE user_id = 123，哪怕只改一行，也会因二级索引（非主键）触发间隙锁，把附近范围一起锁住；再叠加 innodb_flush_log_at_trx_commit = 1（默认），每次提交都强制刷盘，I/O直接成为瓶颈。
- 高频更新非主键字段（如状态、计数器）极易扩大锁范围，比按主键更新慢 3~10 倍
- 每多一个索引，INSERT/UPDATE 就得多维护一棵 B+ 树，写放大效应明显
- 事务过大（如单次改 2 万行）会导致 undo 日志膨胀、锁持有时间过长、崩溃恢复变慢
必须调的三个InnoDB参数
不改配置，光靠SQL优化只能解决一半问题。以下三个参数在生产环境几乎必调，且效果立竿见影：
-
innodb_flush_log_at_trx_commit = 2：事务提交时不强制刷盘，只写入 OS 缓存，崩溃可能丢失最多 1 秒数据，但写入吞吐可提升 3~10 倍 -
innodb_log_file_size = 1G（或更大）：增大 redo log 文件大小，减少 checkpoint 频率；注意不能热修改，需停机删除旧日志后重启 -
innodb_buffer_pool_size = 20G（设为物理内存 60%~70%）：缓冲池越大，越少读盘、越少刷脏页，对写入链路中的页加载和刷新都有正向影响
批量写入时怎么控制batch大小
批量 INSERT 确实快，但 batch 不是越大越好。500 行和 2000 行实际吞吐差异不大，反而容易触发事务超时、内存溢出或锁等待加剧。
- 单条
INSERT INTO t(a,b) VALUES (1,2),(3,4),...,(n,m)建议控制在 500~1000 行/批，单行数据越宽，batch 越小 - 用
LOAD DATA INFILE导入时，先执行SET UNIQUE_CHECKS=0和SET AUTOCOMMIT=0，导入完再开 - 应用层做写缓冲（如 Kafka 消费者攒批）时，建议按时间（如 200ms）+ 数量（如 200 条）双触发，避免延迟毛刺
哪些操作看似合理实则加重写压力
有些写法在逻辑上没问题，但在高并发下会放大锁竞争或 I/O 开销，容易被忽略：
- 用
SELECT ... FOR UPDATE查后再更新，不如直接UPDATE t SET cnt = cnt + 1 WHERE id = ?原子操作——前者至少两次加锁，后者一次完成 - 给写多读少的表建太多二级索引，比如订单表加了 5 个非必要索引，写入性能直接打五折
- 在事务里调远程接口或做复杂计算，导致事务生命周期拉长，锁持有时间被动延长
