SQL如何监控表级锁的争用情况_Table_locks_waited状态变量分析

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，这种写法在高并发下必然撞锁。