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查锁等待）和压测验证。
