批量导入锁表超时本质是锁范围过大：无索引导致全表扫描并加行锁甚至升级为表锁，或repeatable-read下间隙锁覆盖过广；分批提交需控制batch_size（500–2000）并及时commit。
批量导入数据时锁表超时，本质不是“锁太久”，而是“锁了不该锁的范围”——多数情况是没走索引导致行锁退化为表锁，或间隙锁覆盖过大。
为什么批量 INSERT/UPDATE 会锁表而不是只锁行
InnoDB 的行级锁只在明确命中索引时生效。一旦 WHERE 条件或 JOIN 字段缺失索引，MySQL 就会执行全表扫描，同时对所有扫描过的行加锁（甚至升级为表锁）。你看到的“锁表”，其实是锁了成千上万行+间隙，其他事务一碰就卡住。
- UPDATE t_user SET status = 1 WHERE email = 'x@y.z' —— 如果
email没有索引，整张表被扫描并加锁 - INSERT INTO t_log (...) SELECT ... FROM t_source —— 若
t_source上的关联字段无索引，SELECT 阶段就可能持锁过久 - REPEATABLE-READ 隔离级别下，即使只更新 1 行，也会额外加
Gap Lock，阻塞附近 INSERT
分批提交必须控制 batch_size 和事务边界
不分批、大事务提交是锁等待超时最常见诱因。不是“一次插越多越快”，而是“一次插太多，锁持有时间指数级增长”。关键不是总条数，而是单次事务内涉及的索引范围和锁数量。
- 推荐
batch_size设为 500–2000，具体看单行数据大小和索引复杂度；超过 5000 条建议强制拆分 - Python 示例中务必关闭自动提交：
conn.autocommit = False，否则每条语句都成独立事务，反而放大锁竞争 - 每个
executemany后立即conn.commit()，不要等全部 batch 跑完再统一提交 - 避免在循环内嵌套事务：比如外层
@Transactional+ 内层手动commit()，容易造成事务嵌套失控
如何快速定位当前是谁在持锁不放
别猜，直接查。锁等待超时发生后，第一件事是确认阻塞源头，而不是调参数。
- 运行
SHOW ENGINE INNODB STATUS\G，重点找LATEST DETECTED DEADLOCK或TRANSACTIONS段里的长时间 RUNNING 状态事务 - 查活跃事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5，看trx_state和trx_started时间 - 查锁等待关系：
SELECT * FROM sys.innodb_lock_waits\G，其中blocking_trx_id对应阻塞者，blocking_thread是可 kill 的连接 ID - 若发现
trx_state = "RUNNING"且trx_started几分钟前，大概率是应用端未正确 commit/rollback，需人工干预KILL [blocking_thread]
哪些参数调整真有用，哪些只是掩耳盗铃
调大 innodb_lock_wait_timeout 只是把报错从 50 秒延后到 120 秒，但连接堆积、响应延迟、线程耗尽的问题照旧。真正有效的调整必须配合行为改变。
- 临时生效可设：
SET SESSION innodb_lock_wait_timeout = 60（仅当前连接），但上线前必须验证是否掩盖了慢 SQL - 降低隔离级别更治本：
SET SESSION transaction_isolation = 'READ-COMMITTED'，能消除间隙锁，大幅减少 INSERT 阻塞 -
innodb_flush_log_at_trx_commit = 2可提速，但注意：崩溃可能丢失最近 1 秒事务，勿用于金融类强一致性场景 - 禁用唯一索引？千万别。用
ALTER TABLE t DROP INDEX导入再重建，虽快但风险极高——重复数据会静默失败或爆错，且 DROP INDEX 本身会锁表
最容易被忽略的一点：批量操作前先 EXPLAIN 你的 UPDATE/INSERT SELECT 语句，确认 type 是 range 或 ref，而不是 ALL。只要出现 ALL，就等于告诉 MySQL：“请锁全表”。
