MySQL无通用解锁命令，需终止会话或提交/回滚事务；通过SHOW PROCESSLIST、INNODB_TRX等查锁源，用KILL释放；显式LOCK TABLES须同连接UNLOCK TABLES；应避免长事务与显式锁，优先用InnoDB行锁。
MySQL中表被锁通常是因为事务未提交、客户端异常断开或执行了LOCK TABLES语句。解锁的关键是终止持有锁的会话或提交/回滚事务，而不是直接“解锁表”命令——MySQL没有类似UNLOCK TABLES（针对显式锁定）以外的通用解锁指令。
查看当前锁和阻塞情况
先确认哪些线程在占用锁、是否存在锁等待：
- 执行SHOW PROCESSLIST; 查看所有连接及状态，重点关注State列（如"Sending data"、"Locked"、"Waiting for table metadata lock"）
- 查询SELECT * FROM information_schema.INNODB_TRX; 获取正在运行的InnoDB事务，注意trx_state、trx_started、trx_mysql_thread_id
- 检查锁等待：SELECT * FROM information_schema.INNODB_LOCK_WAITS;（需MySQL 5.6+）
- 查看元数据锁：SELECT * FROM performance_schema.metadata_locks;（需开启performance_schema且相关instrument启用）
终止异常会话释放锁
找到阻塞源后，用KILL命令结束对应线程：
- 从SHOW PROCESSLIST; 或INNODB_TRX; 中获取线程ID（Id或trx_mysql_thread_id）
- 执行KILL [thread_id];（例如KILL 1234;）
- 注意：KILL仅中断连接，不会自动回滚事务；若事务已修改数据，KILL后InnoDB会自动回滚该事务并释放行锁/表锁
处理显式LOCK TABLES导致的锁
如果使用了LOCK TABLES ... WRITE/READ，必须由同一连接执行UNLOCK TABLES;才能释放：
- 不能跨连接解锁，也不能用KILL替代（KILL会断开连接，但可能引发不一致）
- 若客户端已断开，MySQL会自动清理该连接持有的表锁
- 建议避免在应用中使用LOCK TABLES，优先依赖InnoDB的行级锁和事务机制
预防锁问题的实用建议
减少锁冲突比事后解锁更重要：
- 事务尽量短小，及时COMMIT或ROLLBACK，避免长事务持有锁
- 按固定顺序访问多张表，防止死锁
- 写操作加索引，避免全表扫描升级为表级锁（尤其MyISAM）
- 监控slow_query_log和Performance Schema，定位慢SQL和锁热点
