MySQL频繁table lock争用主因是MDL被长期持有，如长事务未提交、LOCK TABLES未释放、备份工具加高优先级MDL锁等；需通过performance_schema.metadata_locks定位持有者，而非仅依赖SHOW PROCESSLIST。

MySQL频繁发生 table lock 争用，基本可以断定不是InnoDB行锁失效那么简单——大概率是元数据锁（MDL）被长期持有，或查询/DDL操作触发了隐式表级锁定。直接杀进程只能治标，必须定位锁源、切断升级路径。

为什么SHOW PROCESSLIST里总看到“Waiting for table metadata lock”

这个状态不是普通DML造成的，而是某条语句正阻塞着DDL或另一条DML对表结构的访问。常见原因有：

• 一个长事务未提交，且里面执行过 SELECT 或 UPDATE 某张表——哪怕只是读，也会在该表上持有一个 MDL_SHARED_READ 锁，阻止后续 ALTER TABLE
• 某个会话执行了 LOCK TABLES t1 READ 但没执行 UNLOCK TABLES，整个连接卡在那，锁一直不释放
• 备份工具（如 mysqldump --single-transaction）在RR隔离级别下启动时，会先对所有表加 MDL_SHARED_HIGH_PRIO，若此时有慢查询正在执行，就会被卡住
• MySQL 5.7+ 中，FLUSH TABLES WITH READ LOCK 会全局阻塞所有DDL和DML，极易引发大面积等待

如何快速定位谁在 hold MDL 锁

不能只看 SHOW PROCESSLIST，它不显示MDL持有者。必须查 performance_schema：

SELECT
  OBJECT_SCHEMA,
  OBJECT_NAME,
  LOCK_TYPE,
  LOCK_DURATION,
  LOCK_STATUS,
  OWNER_THREAD_ID,
  OWNER_EVENT_ID
FROM performance_schema.metadata_locks
WHERE OWNER_THREAD_ID IN (
  SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_COMMAND != 'Sleep'
);

重点关注 LOCK_STATUS = 'PENDING' 的行，再反查 OWNER_THREAD_ID 对应的 PROCESSLIST_INFO（从 performance_schema.threads 表里拿），就能知道是哪条SQL在等锁、谁在占着不放。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

注意：metadata_locks 表默认关闭，需提前启用：

SET GLOBAL performance_schema = ON;
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';

哪些操作会意外触发表锁升级

InnoDB本不该轻易升到表锁，但以下情况会让它“放弃挣扎”：

• UPDATE 或 DELETE 语句 没走任何索引（EXPLAIN 显示 type=ALL），引擎被迫全表扫描，为保证一致性，会对所有扫描过的行加锁——而如果扫描行数超阈值（默认约2000行），InnoDB可能直接升级为表级意向锁，导致其他事务无法修改该表
• 在 READ COMMITTED 隔离级别下执行 SELECT ... FOR UPDATE 且无索引条件，同样可能锁全表
• MyISAM 表混在同一个库中，任何对该表的写操作都会触发整表独占锁，影响所有并发访问
• CREATE TEMPORARY TABLE 如果名字和已有表冲突，也可能短暂申请MDL排他锁，与其它会话形成竞争

真正有效的缓解策略不是加索引，而是控制锁生命周期

索引只是辅助，核心是让锁“短、快、准”：

• 禁止应用层开启事务后长时间空闲：在代码里加 innodb_lock_wait_timeout=10（而非默认50），并捕获 Lock wait timeout exceeded 异常主动回滚
• DDL操作一律用 pt-online-schema-change，避免 ALTER TABLE 直接抢MDL；尤其禁止在业务高峰跑 CREATE INDEX
• 监控 information_schema.INNODB_TRX 中 trx_started 超过60秒的事务，自动告警并记录 trx_query 内容
• 把 LOCK TABLES 这类显式语句从代码里彻底清除——它和 UNLOCK TABLES 很难配对，极易遗留锁

最易被忽略的一点：autocommit=0 的连接一旦异常断开，事务不会自动回滚，MDL锁也不会释放，这种“幽灵锁”可能持续数小时。务必确保所有客户端设置了 wait_timeout 和 interactive_timeout 并合理调低（比如300秒）。