MyISAM表锁导致应用超时是因为其仅支持表级锁，任何写操作都会阻塞其他读写；应通过SHOW PROCESSLIST查看State为“Waiting for table level lock”的等待线程及Time值大的持有锁线程，并确认引擎为MyISAM后精准kill持锁线程。
MyISAM表锁导致应用超时，基本就是整张表被一个慢查询或长事务卡死，其他所有写操作（甚至部分读）都会排队等待——这不是“可能”，而是必然发生。
查 SHOW PROCESSLIST 里有没有 Waiting for table level lock
这是最直接的信号。MyISAM不支持行锁，任何写操作（UPDATE、DELETE、INSERT）都会对整张表加写锁，而写锁会阻塞后续所有写，以及在某些情况下阻塞读（比如有未完成的写锁时，新来的SELECT也可能被挂起）。
- 执行
SHOW PROCESSLIST;，重点关注State列 - 只要看到多个线程的
State是Waiting for table level lock，且Info字段指向同一张 MyISAM 表（比如都卡在UPDATE t_myisam SET ...），基本可以锁定问题源 - 同时留意那个
State是Query或Sending data、但Time值很大的线程——它大概率就是持有表锁的“元凶”
确认表引擎是不是 MyISAM
别凭印象判断，有些老系统混用引擎，或者迁移后漏改。误判为 InnoDB 会浪费大量排查时间。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 查表结构：
SHOW CREATE TABLE `table_name`;，看末尾是不是ENGINE=MyISAM - 批量检查：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine = 'MyISAM'; - 注意：即使业务逻辑没动这张表，
OPTIMIZE TABLE或异常崩溃后的自动修复（REPAIR TABLE）也会触发 MyISAM 表级锁，且持续时间不可控
为什么不能只 kill 掉等待线程？
杀错对象毫无意义。等待线程（Waiting for table level lock）只是受害者，真正要处理的是那个正在执行、尚未完成的线程。
- 等待线程 KILL 后会立刻重试，马上又卡住，治标不治本
- 持有锁的线程可能是：
SELECT ... FROM t_myisam WHERE ...（MyISAM 的读不加锁，但长查询会拖慢整体响应；更危险的是它可能正被其他写锁阻塞，形成连锁反应） - 也可能是：
UPDATE t_myisam SET ...卡在磁盘 I/O、网络延迟，或根本就是个没索引的全表更新 - 务必用
ID字段定位到持有锁的线程，再决定是否KILL；若不确定，先EXPLAIN它的INFO语句，看是否走全表扫描
MyISAM 表锁问题最容易被忽略的点
不是锁本身难理解，而是它的“传染性”和“隐蔽性”常被低估：
- 一张 MyISAM 表出问题，可能拖垮整个库连接池——因为等待线程不释放连接，应用层连接数很快打满
-
LOCK TABLES t_myisam WRITE;这种显式锁一旦没配对UNLOCK TABLES，锁会一直挂着，且SHOW PROCESSLIST不会显示异常状态，只能靠人工核对 - MyISAM 没有事务，
ROLLBACK无效，所以“忘记提交”这类问题在 InnoDB 里是长事务，在 MyISAM 里压根不存在——但“忘记解锁”或“查询卡死”一样致命
