MySQL高并发写入瓶颈主因是锁竞争、磁盘I/O、事务开销和索引维护；优化需减少争用、批量处理、合理拆分压力并轻量化写操作。
MySQL 高并发写入性能瓶颈通常出现在锁竞争、磁盘 I/O、事务开销和索引维护上，而非单纯 CPU 或内存不足。优化核心是减少争用、批量处理、合理拆分压力，并让写操作尽可能“轻量”。
减少行锁与间隙锁争用
InnoDB 默认使用行级锁，但高并发更新同一索引范围（如时间戳、状态字段）会触发间隙锁（Gap Lock），导致大量事务阻塞。常见于“插入+更新混合”或“按非主键条件更新”的场景。
- 优先使用主键或唯一索引更新，避免 WHERE 条件走非唯一二级索引（易扩大锁范围）
- 将高频更新字段（如计数器、状态）从主表剥离到独立宽表或汇总表，用异步方式合并
- 业务允许时，把“SELECT + UPDATE”改为原子操作：如
UPDATE t SET cnt = cnt + 1 WHERE id = ?，避免先查后更带来的锁等待 - 评估是否可临时关闭
innodb_locks_unsafe_for_binlog（5.6+ 已废弃，实际应调低隔离级别至 READ-COMMITTED）
提升批量写入吞吐能力
单条 INSERT/REPLACE/UPDATE 在高并发下开销巨大——每条语句都经历解析、优化、加锁、刷日志、刷数据页等流程。批量操作能显著摊薄单位开销。
- 用
INSERT INTO ... VALUES (...), (...), (...)一次插入多行（建议 500~2000 行/批，视单行大小调整） - 大批量导入时启用
LOAD DATA INFILE，比 INSERT 快 5~20 倍；注意关闭唯一性检查（SET UNIQUE_CHECKS=0）和自动提交（SET AUTOCOMMIT=0）再执行 - 应用层做写缓冲：如 Kafka + 消费者聚合 N 秒内请求，再批量落库；避免每笔请求直写 MySQL
- 对日志类、埋点类无强一致性要求的数据，可先写入本地文件或 Redis，定时归档入库
优化事务与日志行为
长事务、频繁提交、过大的 redo log 写入都会拖慢写入速度。InnoDB 的写性能高度依赖日志刷盘策略与事务粒度。
- 控制事务大小：单个事务修改行数建议 ≤ 5000 行，避免 undo 日志膨胀和锁持有时间过长
- 调整
innodb_flush_log_at_trx_commit = 2（崩溃可能丢失 1 秒数据，但写入吞吐可提升 3~10 倍）；若搭配sync_binlog = 0可进一步加速，需权衡可靠性 - 增大
innodb_log_file_size（如 1G~4G），减少 checkpoint 频率；注意调整需停机且不能直接改配置文件，需删除旧日志后重启 - 避免在事务中做耗时操作（如远程调用、复杂计算），缩短事务生命周期
合理设计表结构与索引
每新增一个索引，INSERT/UPDATE/DELETE 就要额外维护一份 B+ 树，写放大效应明显。尤其在写多读少场景，索引越多，写越慢。
- 删除未被查询使用的冗余索引（可用
performance_schema.table_io_waits_summary_by_index_usage分析） - 高频写入表慎用 UUID 或随机字符串作主键（导致聚簇索引分裂严重），优先自增整型或有序雪花 ID
- 大字段（TEXT/BLOB）分离到附表，主表只留关键查询字段，减少行长度和 buffer pool 压力
- 考虑分区表（RANGE/LIST）按时间或业务维度拆分，限制单次写入影响范围（注意 MySQL 8.0+ 对分区表 DML 优化已增强）
不复杂但容易忽略。真正压测时，往往一个没关的 auto-commit、一条没走主键的 update、或者一个没人用的索引，就是写入瓶颈的根源。
