为什么 INSERT
在高并发下会卡住？
根本原因不是 MySQL 本身慢，而是锁、事务隔离级别和磁盘 I/O 共同拖慢了写入路径。默认的
REPEATABLE READ隔离级别下，普通
INSERT会加间隙锁（gap lock），多个线程往同一索引范围插入时容易相互阻塞；同时，如果没关掉
autocommit，每个
INSERT都是独立事务，频繁刷 redo log 和 binlog 会造成 I/O 瓶颈。 确认当前隔离级别：
SELECT @@transaction_isolation;，生产环境高并发写建议设为
READ-COMMITTED（需配合
binlog_format=ROW） 批量插入必须用
INSERT INTO ... VALUES (...), (...), (...)，单条
INSERT每次都走完整事务流程，吞吐量差一个数量级 避免在写密集表上建过多二级索引——每多一个索引，一次写就要更新多个 B+ 树，延迟直接翻倍
如何让 INSERT
不锁表又不丢数据？
核心思路是把“强一致性”和“高吞吐”拆开：写入先落缓存或队列，再异步刷库；数据库层则通过配置降低同步开销，但必须守住持久化底线。
关闭innodb_flush_log_at_trx_commit=2（每秒刷一次 redo log），可提升 3–5 倍写入速度，断电最多丢 1 秒数据；若要求更高可靠性，至少保留为
1（每次事务都刷盘） 启用
innodb_doublewrite=ON必须保持开启——它防止页写入一半崩溃导致数据页损坏，关掉可能引发不可恢复的 corruption 用
LOAD DATA INFILE替代大批量
INSERT，前提是数据已预处理成文本文件；注意检查
secure_file_priv路径限制
INSERT ... ON DUPLICATE KEY UPDATE
在并发下为什么报死锁？
这不是语法问题，而是 MySQL 对唯一键冲突的处理机制触发了额外的锁等待。当两个事务几乎同时插入相同唯一键值，其中一个成功插入后，另一个会尝试升级为
UPDATE锁，但此时前一个事务还没提交，就卡在等待 S 锁或 X 锁上。 优先用
INSERT IGNORE+ 应用层重试，避开锁升级逻辑；适合“有就跳过、无则插入”的场景 如果必须更新，把
ON DUPLICATE KEY UPDATE的更新字段控制在最少——只更新计数器类字段，避免更新大文本或频繁变更字段，减少锁持有时间 确保唯一索引是紧凑的，比如用
(user_id, event_type)而非
(user_id, event_type, created_at)，后者会让 gap lock 范围变大，加剧冲突
分表和写分离真能解决写瓶颈吗？
能，但前提是瓶颈确实在单表容量或主库写入能力上。盲目分表反而增加应用复杂度和跨分片事务成本。真正该先做的，是确认瓶颈点：
SHOW ENGINE INNODB STATUS\G查
SEMAPHORES和
TRANSACTIONS部分，看是不是锁等待或 log buffer 等待过高。 水平分表推荐按写入热点字段哈希（如
user_id % 16），别用时间范围分——会导致新表瞬间写爆，老表长期闲置 读写分离对写性能零提升，只缓解主库查询压力；从库延迟高时，
INSERT后立刻
SELECT可能读不到，得靠应用层加缓存或强制走主库 考虑替代方案：写入先打到 Kafka 或 Pulsar，用 Flink/Spark Streaming 落库，MySQL 只做最终状态存储，彻底解耦实时写和落地节奏
最常被忽略的一点：没有监控就调优等于蒙眼开车。至少要盯住
Innodb_row_lock_waits、
Threads_running和
Slow_queries这三个状态变量，它们比任何理论都更快暴露真实瓶颈。
