MySQL中MyISAM引擎的表不可能发生死锁，因其无事务、无行锁、无死锁检测机制，所有阻塞均为表级锁等待；排查需用SHOW PROCESSLIST和SHOW OPEN TABLES，迁移至InnoDB是根本解法。
MyISAM 表根本不会死锁，你遇到的是表级锁等待
直接说结论：MySQL 中 MyISAM 引擎的表 不可能发生死锁。它没有事务、没有行锁、没有死锁检测机制，所有“卡住”“超时”“长时间无响应”，都是写操作（如 INSERT、LOAD DATA INFILE）触发的**表级锁等待**。用排查 InnoDB 死锁的方式（比如 SHOW ENGINE INNODB STATUS）完全无效，只会浪费时间。
导入大 SQL 转储时卡住，先查 SHOW PROCESSLIST 和 SHOW OPEN TABLES
真正有效的定位命令只有两个：
-
SHOW PROCESSLIST：找State列为Locked或Waiting for table level lock的线程，它们就是被阻塞或正在持锁的导入任务 -
SHOW OPEN TABLES WHERE In_use > 0：确认哪些 MyISAM 表当前正被写锁强占（In_use > 0表示有线程持有写锁）
注意：information_schema.INNODB_LOCK_WAITS 这类表对 MyISAM 完全不适用，查出来永远为空。
导入 SQL 转储时避免长锁表的实操办法
核心思路是不让单条语句独占整张表太久。MyISAM 导入卡顿几乎都源于批量 INSERT VALUES (),(),() 或未加修饰的 LOAD DATA INFILE：
- 拆分大 INSERT：把一次性插入上万行的语句，改成每批
500–1000行执行一次INSERT - 用
LOAD DATA INFILE时加LOW_PRIORITY（例如LOAD DATA LOW_PRIORITY INFILE 'xxx.sql' INTO TABLE t1），让读请求能插队 - 避免在高峰期导入；若必须改结构（如加字段），别直接
ALTER TABLE，改用原子切换：CREATE TABLE t1_new LIKE t1→INSERT INTO t1_new SELECT * FROM t1→RENAME TABLE t1 TO t1_bak, t1_new TO t1 - 如果导入脚本里混用了 MyISAM 和 InnoDB 表，且包裹在事务中，MyISAM 操作虽不参与事务，但会拖慢整个连接释放，建议剥离 MyISAM 操作到独立连接中执行
最省事也最彻底的解法：把 MyISAM 表迁到 InnoDB
这不是“优化建议”，而是当前 MySQL 生态下的事实性要求。InnoDB 自 5.6 起已支持全文索引，压缩表等少数 MyISAM 特性也有替代方案。只要你的业务不强依赖 MyISAM 的 COMPRESSED 表或极老版本的全文检索语法，就该立刻执行迁移：
- 检查表引擎：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine = 'MyISAM'; - 单表转换：
ALTER TABLE t1 ENGINE = InnoDB;（注意：大表需预留足够磁盘空间和执行时间） - 导入前统一改引擎，比导入后修复锁问题成本低得多
真正容易被忽略的是：很多人反复调优 LOAD DATA 参数或重写导入逻辑，却没意识到问题根源是引擎选型——MyISAM 在现代 OLTP 场景下，锁模型本身就是不可扩展的硬伤。
