myisam表不会发生死锁，因其仅支持表级锁且无事务机制；所谓“卡住”实为锁等待，应使用show processlist和show open tables排查，根本解决方式是迁移到innodb。
MyISAM 表不会发生死锁——这不是优化建议，而是事实判断。你看到的“卡住”“超时”“长时间等待”，全是锁等待（lock wait），不是死锁（deadlock）。强行按死锁思路排查，只会浪费时间。
为什么 SHOW ENGINE INNODB STATUS 查不到 MyISAM 的“死锁”
因为 MyISAM 没有事务、没有死锁检测机制、也不维护锁队列。该命令只输出 InnoDB 引擎的内部状态，对 MyISAM 完全无效。你执行它，要么返回空，要么显示无关的 InnoDB 信息。
真正该查的是：
-
SHOW PROCESSLIST：找State列为Locked或Waiting for table level lock的线程 -
SHOW OPEN TABLES WHERE In_use > 0：确认哪些表正被写锁强占（In_use > 0表示有线程持有写锁）
MyISAM 锁等待的典型触发点
所有阻塞都源于它的表级锁特性：一次写操作（INSERT、UPDATE、DELETE、REPLACE、ALTER TABLE）会独占整张表，其他读写全部排队。
常见诱因包括：
- 单次
INSERT ... VALUES (),(),...插入上万行，锁表数秒甚至分钟 - 用
LOAD DATA INFILE导入大文件，未加LOW_PRIORITY - 高峰期执行
ALTER TABLE（哪怕只是加字段，MyISAM 也要全表拷贝重建） - 普通
SELECT与写操作争抢锁（默认不加优先级，会被写锁阻塞） - 事务中混用 MyISAM 和 InnoDB 表（MyISAM 不参与事务，但会拖慢连接释放）
如何快速定位和缓解 MyISAM 锁等待
不能“解决死锁”（因为不存在），但能大幅缩短锁表时间和排队深度：
- 批量写入拆成每 500–1000 行一批，避免单条巨量
INSERT - 读密集场景下，非关键查询显式加
SQL_NO_CACHE，必要时用SELECT HIGH_PRIORITY抢锁（慎用） - 写操作优先用
INSERT LOW_PRIORITY，让读请求优先通过（INSERT DELAYED在 MySQL 8.0 已移除） - 必须改结构时，用原子切换：
CREATE TABLE new LIKE old→INSERT INTO new SELECT * FROM old→RENAME TABLE old TO old_bak, new TO old
最根本的缓解方式不是调优，而是迁移：除非你明确依赖 MyISAM 的全文索引（InnoDB 自 5.6 起已支持）或压缩表特性，否则应尽快把表引擎改为 InnoDB。这不是“可选项”，而是当前版本下对 MyISAM 表锁问题的唯一根治路径。
