显式锁表（LOCK TABLES）导致阻塞的典型现象是其他会话对被锁表的所有读写操作立即卡住，表现为SELECT等待、DML hang、State显示Waiting for table metadata lock或Locked，且该锁不出现在INNODB_LOCKS中，但可在OPEN TABLES和performance_schema.metadata_locks中查到。
显式锁表（LOCK TABLES）导致阻塞的典型现象
执行 LOCK TABLES table_name WRITE 后，其他会话对这张表的所有读写操作都会立刻卡住，表现为：SELECT 返回等待、INSERT/UPDATE/DELETE 一直 hang、SHOW PROCESSLIST 中对应会话的 State 显示为 Waiting for table metadata lock 或直接是 Locked。注意：这种锁不会出现在 INNODB_LOCKS 视图里（因为不是 InnoDB 行锁），但会在 OPEN TABLES 和 performance_schema.metadata_locks 中暴露。
快速定位 LOCK TABLES 持有者的关键命令
显式锁表不走事务引擎管理，所以不能靠 information_schema.innodb_trx 查，得从元数据锁和打开表状态入手：
-
SHOW OPEN TABLES WHERE In_use > 0;—— 直接看到哪些表正被显式锁定（In_use = 1），且Name_locked = 0表示是LOCK TABLES而非 DDL 引起的 MDL 锁 -
SELECT * FROM performance_schema.metadata_locks WHERE LOCK_TYPE = 'TABLE' AND OWNER_THREAD_ID IS NOT NULL;—— 找出持有TABLE级别锁的线程 ID，再关联performance_schema.threads查用户名和 SQL -
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST ORDER BY TIME DESC LIMIT 20;—— 结合TIME和STATE快速筛出长时间空闲但仍在持锁的连接（比如执行完LOCK TABLES就没后续动作了）
KILL 持锁会话前必须确认的三件事
显式锁表只能由持有锁的会话自己 UNLOCK TABLES 或断开连接释放，KILL 是唯一外部干预手段，但容易误伤：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先确认该会话是否还在执行关键逻辑（比如正在做归档迁移），
INFO字段为空或只有SLEEP通常可安全 KILL - 检查
USER和HOST是否属于运维脚本或定时任务——这类连接常因异常退出未清理锁，KILL 后不会影响业务 - 避免 KILL 连接池中活跃连接（如应用连接池里的长连接），否则可能触发重连风暴；优先查
TIME > 300且COMMAND = 'Sleep'的会话
预防 LOCK TABLES 事故的硬性约束
生产环境几乎不该出现 LOCK TABLES，它和 InnoDB 行锁机制天然冲突，排查成本远高于收益：
- 禁止在应用代码或运维脚本中使用
LOCK TABLES ... WRITE，改用事务 +SELECT ... FOR UPDATE控制并发写入 - 如果必须批量操作（如数据迁移），用
pt-online-schema-change替代ALTER TABLE，它内部规避了显式表锁 - 数据库账号权限最小化：撤销普通账号的
LOCK TABLES权限（REVOKE LOCK TABLES ON *.* FROM 'user'@'%';）
真正麻烦的不是锁本身，而是显式锁表后没人知道谁锁的、为什么锁、锁了多久——它不记录在事务日志里，也不受 autocommit 控制，一旦漏掉 UNLOCK TABLES，就只能靠人肉翻 PROCESSLIST 和监控告警去捞。
