MyISAM表锁阻塞需查PROCESSLIST中Waiting for table level lock线程，结合SHOW OPEN TABLES定位持有锁的表，KILL CONNECTION释放锁；避免混用引擎、慎用LOCK TABLES，批量INSERT优化是唯一有效SQL改进。
查看当前正在执行的锁等待线程
MyISAM 本身不支持行级锁，但表级锁冲突仍会表现为线程卡在 Waiting for table level lock 状态。直接查 information_schema.PROCESSLIST 是最快速的定位方式。
- 运行
SELECT * FROM information_schema.PROCESSLIST WHERE STATE = 'Waiting for table level lock';，重点关注ID、USER、HOST、DB、COMMAND和TIME - 注意
TIME值过长（比如 >60 秒）的线程，大概率是被某个长事务或未提交的LOCK TABLES持有锁阻塞 - 如果
INFO字段为空，说明该线程没在执行 SQL，只是卡在锁等待；若非空，可结合SHOW FULL PROCESSLIST看完整语句
确认哪个线程持有 MyISAM 表锁
MySQL 不像 InnoDB 那样提供 INNODB_TRX 视图来查锁持有者，MyISAM 的锁是隐式、语句级的——只要一个线程在对某张 MyISAM 表执行写操作（INSERT、UPDATE、DELETE、REPLACE 或显式 LOCK TABLES ... WRITE），其他线程读该表就会排队。
- 用
SHOW OPEN TABLES WHERE In_use > 0;查哪些 MyISAM 表当前被“占用”（In_use表示持有锁的线程数） - 配合
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE ENGINE = 'MyISAM' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');先确认目标表确实是 MyISAM 引擎 - 特别注意：
SELECT本身不加锁，但一旦前面有未完成的写操作，后续所有读都会等——所以不能只盯住SELECT线程，得顺藤摸瓜找它前面那个没结束的UPDATE或INSERT
快速释放阻塞锁的实操动作
MyISAM 没有死锁检测，锁释放完全依赖原操作结束或客户端断开。不能靠 KILL 来“解锁”，只能终止持有锁的线程本身。
- 拿到上一步查出的阻塞源头线程
ID（不是等待者，是State为Updating/Writing to net/Locked的那个），执行KILL [ID] - 慎用
KILL QUERY [ID]：它只中断当前语句，但若线程刚执行完LOCK TABLES t1 WRITE还没做后续操作，KILL QUERY不会释放锁，必须用KILL（即KILL CONNECTION） - 如果应用用了连接池，
KILL后该连接可能被复用，导致新请求继续卡住——需同步检查应用层是否漏了UNLOCK TABLES或事务未正常退出
避免 MyISAM 表锁问题的硬约束点
MyISAM 的锁机制决定了它不适合高并发写场景，很多“优化”其实是绕不开的根本限制。
- 不要在事务中混用 MyISAM 和 InnoDB 表：MyISAM 不支持事务，
ROLLBACK对它无效，且会干扰整体锁行为 -
concurrent_insert=ON只对INSERT追加有效，不影响UPDATE或DELETE的锁粒度，别误以为开了就万事大吉 - 批量写入时，用
INSERT ... VALUES (...), (...), (...)代替多条单行INSERT，减少锁获取/释放次数——这是唯一能明显改善的 SQL 写法层面操作
真正棘手的是：MyISAM 表锁状态不会记录到 slow log 或 general log，也没有对应的 performance_schema 表可查历史锁等待。一旦问题过去，线索就彻底消失。
