MyISAM引擎不支持死锁，因其仅使用表级锁且无事务机制；所谓“卡住”实为锁等待，应通过SHOW PROCESSLIST和SHOW OPEN TABLES排查，根本解决方式是迁移到InnoDB引擎。
MyISAM 引擎默认只支持表锁，一旦有写操作（INSERT、UPDATE、DELETE），整张表就被独占锁定，后续所有读写请求都会排队等待 —— 这是阻塞的根源，不是配置错，也不是语法问题，而是引擎设计使然。
为什么MyISAM一写就卡住整个表
MyISAM 没有事务、没有行锁、不支持 MVCC。它的写锁是“全表抢占式”的：
- LOCK TABLES table_name WRITE 会直接阻塞其他所有连接对该表的任何访问（包括 SELECT）
- 即使只是执行一条没走索引的 UPDATE，也会触发隐式全表扫描 + 全表写锁
- ALTER TABLE、OPTIMIZE TABLE 等 DDL 操作也强制加写锁，持续时间可能远超预期
典型现象：监控看到 SHOW PROCESSLIST 中大量线程状态为 Locked 或 Waiting for table level lock；同时 SHOW STATUS LIKE 'Table_locks_waited' 值持续上升。
快速验证当前是否被MyISAM表锁拖慢
先确认问题表确实是MyISAM：
SHOW TABLE STATUS LIKE 'your_table_name';看
Engine 字段是否为 MyISAM。
再查锁争用情况：
-
SHOW STATUS LIKE 'Table_locks_immediate'：立即获得的表锁次数（越高说明读锁并发尚可） -
SHOW STATUS LIKE 'Table_locks_waited'：因锁等待而延迟的次数（> 0 就说明已有阻塞，持续增长就是瓶颈）
如果 Table_locks_waited 明显上升，且对应表 Engine = MyISAM，那基本可以锁定原因。
最有效解法：迁移到InnoDB
这不是“优化建议”，而是事实层面的必要动作：-
ALTER TABLE your_table_name ENGINE=InnoDB;—— 直接转换引擎（注意：需确保磁盘空间充足，大表转换期间会锁表） - 转换后，普通
UPDATE/DELETE只锁匹配行，不再波及全表 -
InnoDB的SELECT默认不加锁（快照读），写操作也只在索引覆盖范围内加行锁 - 务必同步检查并补全索引：
UPDATE或DELETE若仍走全表扫描，InnoDB 也可能升级为表锁（虽然概率极低）
迁移前记得备份，且避免在业务高峰执行 ALTER TABLE —— 它本身就会加表锁。
临时缓解但不可长期依赖的手段
仅适用于无法立刻迁移、又必须撑过短期流量高峰的场景：- 把高频写操作拆成更小批次，比如分页
UPDATE，减少单次锁持有时间 - 读多写少场景下，用
SELECT ... LOCK IN SHARE MODE替代显式READ锁，避免阻塞其他读 - 绝对不要在应用代码里混用
LOCK TABLES/UNLOCK TABLES—— 任意一处异常未执行UNLOCK TABLES，整张表就永久卡死 - 禁用
MyISAM表的DELAY_KEY_WRITE（若开启），它会延迟写索引，加剧锁竞争
真正棘手的地方往往不在锁本身，而在“以为加了索引就能避免表锁”——MyISAM 下即使有索引，某些 WHERE 条件（如函数包裹字段、类型隐式转换）仍会导致索引失效，最终退化为全表扫描+表锁。这点容易被忽略，但比引擎切换更常引发线上阻塞。
