17370845950

会，MySQL并发插入仅在违反主键或唯一键约束时触发Duplicate entry错误；INSERT并行执行，不自动串行化，冲突由唯一性检查和锁机制共同决定。

MySQL 并发插入会不会导致主键/唯一键冲突？

会，但只在违反约束时才报错，不是“自动串行化”。INSERT 本身不加全局锁，多个事务同时执行 INSERT 是并行的；一旦两条语句试图写入相同的 PRIMARY KEY 或 UNIQUE 值，后提交的那个会触发 Duplicate entry 错误（如 ERROR 1062 (23000)）。

典型场景：用自增 ID 一般不会冲突，但用业务生成的 ID（如订单号、UUID 拼接值）、或显式指定 id 插入时，风险明显上升。

• 使用 INSERT IGNORE 可静默跳过冲突行（影响行数为 0）
• 用 ON DUPLICATE KEY UPDATE 可转为更新逻辑
• 用 REPLACE INTO 本质是删+插，可能改变 AUTO_INCREMENT 值，慎用

InnoDB 的行级锁如何影响并发插入？

InnoDB 在插入时会对**插入位置的间隙（gap）加插入意向锁（Insert Intention Lock）**，这是一种轻量级锁，允许多个事务同时往同一个间隙插入不同值——只要不撞上已有记录或彼此重复值。

但以下情况会阻塞：

• 两个事务同时向同一索引间隙插入相同 UNIQUE 值（比如都插 user_id = 100），其中一个会被锁住直到另一个提交或回滚
• 插入前需检查唯一性，而该值正被另一个未提交事务占用（即使还没写入磁盘），此时会等待
• 表没主键或唯一索引时，InnoDB 会用隐式聚簇索引，仍按规则加锁，但冲突面更广

大批量并发 INSERT 的性能瓶颈在哪？

真正卡住的往往不是锁，而是：

• innodb_buffer_pool_size 不足 → 频繁刷脏页、磁盘 I/O 上升
• 频繁提交（每个 INSERT 都 COMMIT）→ redo log 刷盘压力大，事务吞吐骤降
• 唯一索引太多 → 每次插入都要遍历所有唯一索引校验，CPU 和 B+ 树搜索开销叠加
• 自增锁争用（innodb_autoinc_lock_mode = 0 时）→ 批量插入如 INSERT ... SELECT 会持表级自增锁

建议：批量插入用 INSERT INTO ... VALUES (...), (...), (...) 多值语法；控制事务大小（如每 1000 行 COMMIT 一次）；确认 innodb_autoinc_lock_mode 设为 2（默认，适合并发）。

INSERT ... ON DUPLICATE KEY UPDATE 真的线程安全吗？

是的，在单条语句粒度上原子执行。MySQL 会先做唯一键查找，再决定插入还是更新，整个过程持有必要的行锁（或间隙锁），其他并发语句无法在此期间修改同一行。

但要注意：

• 它只对 **匹配到的那一条已有记录** 生效；如果条件命中多行（理论上 UNIQUE 约束下不会），实际行为依赖 MySQL 版本，5.7+ 报错
• 更新字段若引用自身（如 count = count + 1），多次并发执行可能导致结果小于预期（因读-改-写非原子），应改用 INSERT ... VALUES(...) ON DUPLICATE KEY UPDATE count = count + VALUES(count)
• 不能替代应用层的分布式锁，比如跨库、跨表或涉及多步逻辑时，仍需外部协调

INSERT INTO users (id, name, version) 
VALUES (123, 'Alice', 1) 
ON DUPLICATE KEY UPDATE 
  name = VALUES(name), 
  version = version + 1;

并发插入的复杂点不在“能不能做”，而在于你是否清楚每一行插入时，MySQL 底层到底查了哪些索引、加了什么锁、以及事务隔离级别如何放大或缓解这些行为。尤其在高并发写入且依赖唯一约束做幂等时，光靠 SQL 语法不够，得结合监控（如 SHOW ENGINE INNODB STATUS 查锁等待）和压测验证。