MyISAM 表不会发生死锁，因其仅支持表级锁且无事务机制；阻塞现象实为锁等待，非死锁；SHOW ENGINE INNODB STATUS 不显示其状态，应使用 SHOW PROCESSLIST 和 SHOW OPEN TABLES 排查；优化核心是减少锁表时间或迁移至 InnoDB。
MyISAM 表不会发生死锁。 它用的是表级锁，不支持行级并发控制，所以不存在“事务A锁表1等表2、事务B锁表2等表1”这种循环等待——它只会排队，不会僵持。你看到的阻塞、超时、卡住，是锁等待（lock wait），不是死锁（deadlock）。
为什么 SHOW ENGINE INNODB STATUS 看不到 MyISAM 死锁信息
因为 SHOW ENGINE INNODB STATUS 只输出 InnoDB 引擎的内部状态，而 MyISAM 根本没有事务、没有死锁检测机制、也不维护锁队列信息。如果你在 MyISAM 表上遇到“卡住”，查这个命令永远为空或无关内容。
真正该看的是：
-
SHOW PROCESSLIST：找State列为Locked或Waiting for table level lock的线程 -
SHOW OPEN TABLES WHERE In_use > 0：确认哪些表正被强占（In_use> 0 表示有线程持有写锁）
MyISAM 锁等待的根本原因和优化方向
MyISAM 的“长时间锁表”本质是写操作（INSERT、UPDATE、DELETE、REPLACE、ALTER TABLE）会独占整张表，期间所有其他读写请求都得排队。常见诱因包括：
- 大批次
INSERT ... SELECT或LOAD DATA INFILE操作未分批，单次锁表数秒甚至分钟 - 长事务中混用 MyISAM 和 InnoDB 表（MyISAM 不参与事务，但会拖慢整个连接释放）
- 频繁执行
ALTER TABLE（即使只是加字段，在 MyISAM 上也是全表拷贝+重建） - SELECT 查询没加
LOW_PRIORITY，与写操作争抢锁（默认普通 SELECT 也会被写锁阻塞）
如何减少 MyISAM 表锁等待时间
不能防死锁（本来就没有），但能显著降低锁表时长和排队深度：
- 写操作尽量用
INSERT DELAYED（5.6 及以前）或改用INSERT ... LOW_PRIORITY，让写入让位于读请求（注意：DELAYED在 8.0 已移除） - 批量插入拆成每 500–1000 行一批，用多条
INSERT替代单条大INSERT ... VALUES (...),(...),... - 避免在高峰期执行
ALTER TABLE；如必须改结构，先用CREATE TABLE new LIKE old+INSERT INTO new SELECT * FROM old+RENAME TABLE原子切换 - 读密集场景下，对非关键报表类查询显式加
SQL_NO_CACHE并搭配SELECT ... HIGH_PRIORITY（仅当确定要抢锁时） - 最关键的一步：把 MyISAM 表迁到 InnoDB。不是“优化”，而是根治——除非你明确依赖 MyISAM 的全文索引（5.6+ InnoDB 已支持）或压缩表特性，否则没有理由继续用它。
真正容易被忽略的是：MyISAM 的“锁表”问题常被误判为数据库瓶颈，实际根源往往是业务层没做读写分离，或者缓存没兜住高频读。别在锁策略上过度调优，先确认这张表是否还值得保留在 MyISAM 上。
