Table_locks_waited持续增长表明表级锁争用严重，需结合单位时间增幅（如每秒＞0.5次）及与Table_locks_immediate比值（＞5%）判断；它仅统计总数，定位需配合SHOW OPEN TABLES和PROCESSLIST；InnoDB表显式LOCK TABLES或OPTIMIZE/ALTER TABLE等操作也会触发；监控应取差值而非累计值，根治需迁移引擎并清理依赖表锁的旧逻辑。
查 Table_locks_waited 看锁争用是否严重
这个状态变量直接反映 MySQL 服务器层面因表级锁（主要是 MyISAM 表或显式 LOCK TABLES）导致的等待次数。值持续增长，说明有线程在排队等表锁——不是事务锁冲突，而是老式表锁卡住了。
执行 SHOW STATUS LIKE 'Table_locks_waited'; 即可获取当前累计值。注意它不重置，除非服务重启；要判断“是否严重”，得结合业务节奏看单位时间增幅：比如每秒涨 > 0.5 次，基本说明锁瓶颈已出现。
-
Table_locks_immediate是成功立即获得锁的次数，两者比值（waited / (waited + immediate)）超过 5% 就该警惕 - 该变量对 InnoDB 表无效——InnoDB 默认不用表级锁，除非你手动
LOCK TABLES ... WRITE - 如果应用混用了 MyISAM 和 InnoDB，而 MyISAM 表被高频写入，
Table_locks_waited就会跳得明显
定位具体是哪张表在被锁住
Table_locks_waited 只给总数，不告诉你谁在锁、谁在等。真要排查，得靠 SHOW OPEN TABLES WHERE In_use > 0; 配合 INFORMATION_SCHEMA.PROCESSLIST。
SHOW OPEN TABLES 里 In_use 非零，表示该表正被加锁（尤其注意 Write_locks 列）；而 PROCESSLIST 中 State 字段为 Waiting for table level lock 的线程，就是正在干等的那个。
- 重点看
Command是Query且Time值偏大的线程，大概率是长事务或未提交的LOCK TABLES - MyISAM 表执行
INSERT或UPDATE时会自动加写锁，期间所有其他写操作都得排队——哪怕只是另一条INSERT - 避免在应用里写
LOCK TABLES t1 WRITE; ... UNLOCK TABLES;，尤其不要跨语句、跨函数调用，极易遗忘UNLOCK
为什么换成 InnoDB 还看到 Table_locks_waited 上升
不是换引擎就万事大吉。InnoDB 虽默认行锁，但一旦你显式执行 LOCK TABLES，MySQL 仍会施加表级锁（哪怕锁的是 InnoDB 表），此时 Table_locks_waited 同样会计数。
另外，某些管理命令如 OPTIMIZE TABLE（对 MyISAM）或 ALTER TABLE（旧版本、非 ALGORITHM=INPLACE 时）也会触发全表锁，引发等待。
-
FLUSH TABLES WITH READ LOCK是全局表锁，会让所有后续写操作卡住，Table_locks_waited必然飙升 - 备份工具如
mysqldump --lock-all-tables就依赖这个机制，若备份时间长，业务写请求就会堆在锁外 - 检查慢日志里有没有长时间运行的
SELECT ... FOR UPDATE或未提交事务——它们虽不走表锁，但可能间接拖慢LOCK TABLES执行者释放锁的速度
监控脚本里怎么安全取值
别直接用 SHOW STATUS 结果做告警阈值，因为它是累计值。更靠谱的是采集间隔差值，比如每 30 秒跑一次：
SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Table_locks_waited';
然后和上次值相减。注意并发采集时可能遇到主从延迟导致的值不一致，所以务必在主库上查。
- 不要用
information_schema.SESSION_STATUS，它只返回当前连接的局部计数，没意义 - Percona Server 或 MariaDB 提供了
table_lock_waits_summary_by_table等性能模式表，能细化到表名和锁类型，原生 MySQL 8.0+ 也有类似能力，但需开启performance_schema并配置相关 consumers - 如果发现
Table_locks_waited在凌晨批量作业时段突增，先别急着优化 SQL，先查查有没有定时ANALYZE TABLE或REPAIR TABLE在跑
表级锁争用本质是架构层遗留问题，不是调参能根治的。一旦确认是 MyISAM 表导致，迁移表引擎只是第一步；更要紧的是清理掉那些隐式依赖表锁的旧逻辑——比如用 SELECT MAX(id)+1 模拟序列，再 INSERT，这种写法在高并发下必然撞锁。
