根本原因是存储引擎行为、SQL执行方式或配置项触发表级锁：MyISAM强制表锁；InnoDB因缺索引导致全表扫描加行锁堆积；AUTO_INCREMENT插入锁模式不当；或显式LOCK TABLES未释放。
MySQL 在 READ-COMMITTED（RC）隔离级别下仍出现 Waiting for table level lock，根本原因不是隔离级别本身导致的，而是底层存储引擎行为、SQL 执行方式或配置项共同触发了表级锁。InnoDB 默认用行锁，但某些场景会“退化”为全表扫描加行锁，或直接启用真正的表级锁机制。
MyISAM 表强制使用表锁，与隔离级别无关
如果你查的表是 MyISAM 引擎，READ-COMMITTED 完全无效——MyISAM 不支持事务和行级锁，所有 DML（UPDATE/DELETE）和部分 DDL 都会持表锁。哪怕只更新一行，也会锁整张表。
- 确认引擎：
SHOW CREATE TABLE your_table;看ENGINE=MyISAM - 转换方案：
ALTER TABLE your_table ENGINE=InnoDB; - 注意：MyISAM 表在备份（如
mysqldump）时也常触发Waiting for table level lock，即使没显式执行 LOCK TABLE
WHERE 条件未命中索引，导致全表扫描+隐式行锁堆积
InnoDB 的“行锁”依赖索引定位。若 UPDATE 或 DELETE 的 WHERE 条件走不了索引（比如字段无索引、用了函数、类型隐式转换），就会全表扫描——每行都加 X 锁。效果等同于表锁，后续语句全部卡在 Waiting for table level lock（实际是等待某一行释放锁，但因锁太多，看起来像表被锁死）。
- 典型错误：
UPDATE users SET status=1 WHERE phone='138...'，但phone列没索引 - 验证方法：
EXPLAIN FORMAT=TRADITIONAL SELECT * FROM users WHERE phone='138...';看是否type=ALL - 修复动作：给高频查询/更新字段加索引，例如
CREATE INDEX idx_phone ON users(phone);
innodb_autoinc_lock_mode = 0 或 1 时，INSERT AUTO_INCREMENT 触发表级锁
当表含 AUTO_INCREMENT 主键，且 innodb_autoinc_lock_mode 设置为 0（传统模式）或 1（连续模式），批量 INSERT（如 INSERT ... SELECT、REPLACE、带多行 VALUES 的 INSERT）会持有 AUTO-INC 表级锁，阻塞其他对该表的 INSERT/UPDATE。
- 查看当前值：
SELECT @@innodb_autoinc_lock_mode; - 推荐设置：
SET GLOBAL innodb_autoinc_lock_mode = 2;（交错模式，仅对 statement-based binlog 有主从风险） - 注意：该参数需在
my.cnf中持久化，否则重启失效
显式 LOCK TABLES 或 FLUSH TABLES WITH READ LOCK 没释放
LOCK TABLES t1 WRITE 或 FLUSH TABLES WITH READ LOCK 是真正的表级锁指令，它们不依赖事务、不受隔离级别影响。一旦执行却忘记 UNLOCK TABLES，所有后续操作都会卡在 Waiting for table level lock。
- 检查是否残留：
SHOW OPEN TABLES WHERE In_use > 0; - 定位锁源：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME = 't1'; - 紧急释放：
UNLOCK TABLES;（当前会话）或KILL掉对应连接
真正容易被忽略的是：Waiting for table level lock 看似是锁问题，但根源往往不在锁本身，而在 SQL 写法（缺索引）、引擎选型（MyISAM）、或运维操作（没 unlock）。排查时优先看 SHOW PROCESSLIST 中卡住的语句类型，再结合 EXPLAIN 和 information_schema 视图交叉验证，比盲目调参更有效。
