Navicat导入本身不直接触发死锁，但会因与未提交事务争抢资源而引发死锁或阻塞；根本解决需清查并终止隐患事务、避免多线程并发插入、优先采用命令行可控导入。
navicat 导入数据本身不会直接触发死锁，但导入过程若与正在运行的事务（尤其是未提交的 update/delete）发生资源争抢，就极易引发死锁或表级阻塞。临时锁表或降并发只是表象手段，真正要解决的是「隔离冲突源头」和「控制事务粒度」。
为什么 LOCK TABLES 在 Navicat 导入时基本无效
Navicat 的「导入向导」底层使用的是自动提交的 INSERT 语句流，不走显式事务块；而 LOCK TABLES 要求当前连接持有锁、且其他连接无法写入该表——但 Navicat 导入一旦启动，它自己就会尝试写入，立刻触发锁等待甚至死锁。更关键的是：LOCK TABLES 在 InnoDB 中与事务隔离级别冲突，开启 AUTOCOMMIT=1 时锁会立即释放，根本起不到保护作用。
- Navicat 导入默认每条记录单独提交，
LOCK TABLES无法覆盖整个导入周期 - 如果其他连接正持有该表某行的 X 锁（比如一个未 COMMIT 的
UPDATE），你的导入 INSERT 就会卡在主键/唯一索引检查阶段，形成「插入意向锁」等待，进而可能卷入死锁环 - 执行
LOCK TABLES ... WRITE后，你自己的 Navicat 导入操作反而会报错：「Table 'xxx' was locked with a READ lock and can't be updated」
真正有效的导入前检查项（比锁表更重要）
死锁往往不是导入引起的，而是导入撞上了已存在的“隐患事务”。必须先清场：
- 在 Navicat 新建查询窗口，运行
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX，重点看TRX_STATE是running还是lock wait，以及TRX_STARTED时间是否异常久（>5 分钟） - 配合
SHOW PROCESSLIST，筛选出Status含Locked、Updating或长时间Sleep但Command是Query的线程 - 对确认无业务影响的阻塞线程，用
KILL [ID]主动终止（注意不是KILL QUERY [ID]，后者只中断当前语句，事务仍活着） - 检查目标表是否有长事务在做
ALTER TABLE或CREATE INDEX——这类 DDL 在旧版 MySQL 中会锁全表，Navicat 导入必然被堵住
降低并发 ≠ 解决死锁，但能减少触发概率
Navicat 导入设置里的「每批提交记录数」和「启用多线程」是唯二可调的并发参数，它们影响的是你自己的导入节奏，而非与其他事务的协调逻辑：
- 把「每批提交记录数」从默认 1000 改为 100 或 50，能缩短单次事务持有锁的时间，降低与其他事务交叉等待的概率
- 务必关闭「启用多线程导入」——多线程对同一张表并发 INSERT，在高竞争场景下极易因间隙锁（gap lock）顺序不一致，直接构造出死锁环
- 如果源数据允许，提前在 CSV 中按主键排序，再导入；有序插入能显著减少 InnoDB 的 gap lock 范围，这是很多团队忽略的隐藏优化点
最稳妥的替代方案：绕过 Navicat 图形界面
当表重要、数据量大、或线上环境不允许冒险时，图形化导入就是风险源。命令行才是可控路径：
- 先用
mysqldump --no-data导出表结构，确认字符集和引擎正确；再用mysql -u user -p db_name 导入（注意 SQL 文件需含SET autocommit=0;和结尾COMMIT;） - 对于超大 CSV，改用
LOAD DATA INFILE：它由服务端直读文件，不经过客户端解析，锁粒度更优，且支持LOW_PRIORITY或CONCURRENT（MyISAM）等控制选项 - 如果必须用 Navicat，导入前手动执行
SET SESSION innodb_lock_wait_timeout = 30;（默认 50 秒），避免一个卡住的导入拖垮整条链路
死锁不是配置问题，是资源调度的瞬时博弈。盯着「怎么锁表」不如花两分钟查清「谁还拿着锁没放」——那几个 TRX_ID 和 ID 才是真实瓶颈所在。
