INSERT超时需先通过SHOW ENGINE INNODB STATUS\G查TRANSACTIONS中“lock wait timeout exceeded”判断是否锁等待，否则多为写入慢；高频插入卡顿优先排查自增锁模式与唯一键冲突；批量插入应控制单批行数、显式提交事务、合理关闭约束并及时更新统计信息。
INSERT超时是锁等待还是写入慢？先看错误信息
直接查 SHOW ENGINE INNODB STATUS\G，重点找 TRANSACTIONS 部分里带 lock wait timeout exceeded 的条目——这是锁等待超时；如果日志里没这个，但应用层报 timeout 且无明确锁提示，大概率是写入路径本身卡住（如磁盘 I/O 延迟、大事务未提交、redo log 刷盘慢）。别一上来就调 innodb_lock_wait_timeout，它只改等待上限，不解决根本原因。
高频INSERT卡住？检查自增锁和唯一键冲突
当并发 INSERT 突然变慢或批量失败，尤其集中在同一张表，优先排查两类锁：
-
innodb_autoinc_lock_mode是否为 1（传统模式）？高并发插入自增主键时，它会退化成表级锁。建议设为 2（交错模式），但需确认 binlog 格式不是STATEMENT，否则可能主从不一致 - 是否存在重复插入相同唯一键值？比如订单号生成逻辑缺陷、前端重复提交。这时第一个事务持有了
Gap Lock或Next-Key Lock，后续 INSERT 全部阻塞在Insert Intention Lock等待上。用SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT'能快速定位等待方 - 外键约束是否跨表？插入时要查引用表，若引用表上有长事务或缺失索引，也会拖慢 INSERT
批量INSERT总超时？事务大小和批次控制失衡
常见误区是“一次插越多越快”，结果反而触发超时：
- 单批行数别超
max_allowed_packet限制（查SELECT @@max_allowed_packet），MySQL 默认一般 4MB，按平均每行 2KB 算，最多约 2000 行/批 - 显式事务必须配
COMMIT，漏写会导致连接长期持有锁，后续所有操作都被堵死 - 单事务别超 10 万行：InnoDB undo 表空间和 redo log 可能撑不住，
innodb_log_file_size小的话会频繁刷盘，反而更慢 - 别依赖 ORM 的
saveAll()，多数框架默认仍是循环单条。真要批量，得开 JDBC 的rewriteBatchedStatements=true或用原生LOAD DATA INFILE
索引和约束不是背景板，导入前该关就得关
每插一行都校验唯一性、更新二级索引、跑触发器，等于把批量退化成逐行。但关闭有前提：
- MySQL 中可临时关：
SET FOREIGN_KEY_CHECKS = 0、SET UNIQUE_CHECKS = 0，但仅限数据已由上游清洗干净的场景（如离线 ETL 导入） - 关完必须立刻
ANALYZE TABLE，否则优化器统计过期，后续查询可能走错执行计划 - InnoDB 不支持
DISABLE KEYS（那是 MyISAM 的），别白试 - 云数据库（如 RDS）常禁用这两个 SET 指令，此时只能靠调整批次+顺序写入（如主键升序）来压碎片和锁争抢
实际中，INSERT 超时往往不是单一原因，而是锁 + 批次 + 索引三者叠加。最易被忽略的是：你以为在优化写入速度，其实正在制造更隐蔽的锁竞争或缓冲区压力。
