INSERT需等锁，因其在插入前须申请insert intention lock（防间隙冲突）、auto-inc lock（自增ID分配）及唯一约束校验锁（查索引区间），三者任一被占用即阻塞。
INSERT 报锁等待超时，不是语句写错了，而是它正在等另一个事务释放锁 —— 且等不及了。
INSERT 为什么也要等锁？
很多人以为 INSERT 只是“加一行”，不涉及锁竞争。其实不然，InnoDB 在 INSERT 过程中至少可能申请三类锁：
-
Insert Intention Lock：插入前必须检查间隙是否安全，需在目标位置加插入意向锁，与已有Gap Lock或Next-Key Lock冲突时就会卡住 -
AUTO_INC Lock：表有自增主键时，innodb_autoinc_lock_mode = 1（默认）下，批量 INSERT 会持表级自增锁直到语句结束，高并发插入极易互相阻塞 - 唯一约束检查锁：对主键或唯一索引列做存在性校验时，会扫描并锁定相关索引区间；若另一事务正持有该区间的
X锁（比如 UPDATE 未提交），当前 INSERT 就得等
哪些场景最容易触发？
错误日志里看到 Lock wait timeout exceeded; try restarting transaction，大概率不是随机发生，而是集中在以下几类：
- 多个服务/线程并发 INSERT 相同业务单号（如订单号、流水号），应用层生成重复 ID 导致唯一键冲突检查锁排队
- 一个长事务（比如 2 分钟的 UPDATE + 复杂计算）未提交，它持有的行锁和间隙锁把后续所有 INSERT 挡在门外
- 定时任务跑批量 INSERT，SQL 扫描了 80 万行却只插 0 条（
Rows_examined: 862584），慢查询拖长锁持有时间，连带阻塞其他 INSERT - 微服务间嵌套调用：Service A 的 @Transactional 方法刚 INSERT 一行，马上调用 Service B，而 B 也操作同一张表 —— A 没提交，B 就卡死在 INSERT 等锁上
查锁不能只看 innodb_lock_wait_timeout
这个参数只是“等多久就报错”，不是问题根源。更关键的是别混淆两类超时：
-
innodb_lock_wait_timeout：控制行锁等待上限（单位秒），只对当前会话生效，改了对已连接无效 -
lock_wait_timeout：控制元数据锁（MDL）等待上限（单位毫秒），DDL 期间阻塞 INSERT 就靠它，和上面那个完全无关
误调大前者，只会让业务线程挂得更久、连接池更快耗尽；真要诊断，得直接查 INFORMATION_SCHEMA.INNODB_TRX 和 INNODB_LOCK_WAITS，定位 blocking_trx_id 和 waiting_trx_id。
杀进程不是首选，但有时最有效
当确认是某个长事务或卡死连接导致 INSERT 集体超时，临时解法就是 KILL：
- 先查：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_started LIMIT 5;找出运行超 60 秒的事务 - 再查：
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;看谁在等谁 - 最后杀：
KILL [blocking_thread_id];（注意不是 trx_id，是 thread_id）
真正难的不是杀，而是杀完后——那个被干掉的事务到底在干啥？有没有没回滚的中间状态？有没有下游依赖它？这些才是线上不敢轻易动的原因。
