UNLOCK TABLES 是唯一安全的显式释放方式
解锁操作存在几个硬性约束：
UNLOCK TABLES仅对当前会话有效，必须在加锁的同一连接中执行。- 如果执行时遇到
ERROR 1192 (HY000): Can't execute the given command because you have active locked tables.，说明之前使用了LOCK TABLES，需要先解除表锁，才能释放全局锁。 - 脚本中绝不能遗漏
UNLOCK TABLES—— 它不是可选环节，而是必须成对出现的操作。
许多新手误以为锁会自行超时消失，但 MySQL 并没有自动超时机制——必须显式调用 UNLOCK TABLES。常见错误现象：SHOW PROCESSLIST 中大量线程状态为 Waiting for table flush；应用写入请求持续超时；mysqldump --single-transaction 同样会卡住（因为 FTWRL 会阻塞 MVCC 快照的获取）。
主从环境下必须先停 SQL 线程再加锁
MySQL 8.0 的复制线程（特别是 Replication_SQL_Thread）在 FTWRL 执行期间仍可能尝试应用 binlog，导致锁被“绕过”或复制中断。这并不是 Bug，而是设计如此：FTWRL 不会主动终止复制线程。正确的操作顺序是：
- 在从库上先执行
STOP SLAVE SQL_THREAD - 再执行
FLUSH TABLES WITH READ LOCK - 完成备份/迁移操作后，先执行
UNLOCK TABLES - 再执行
START SLAVE SQL_THREAD
如果跳过停止 SQL 线程这一步，SHOW SLAVE STATUS 中的 Seconds_Behind_Master 会急剧增加，甚至出现 Slave_SQL_Running_State: Waiting for table level lock。
别把 read_only=ON 当成 FTWRL 的替代方案
SET GLOBAL read_only = ON 看起来更“轻量”，但它本质上不是锁机制，也不会影响拥有 SUPER 权限的用户（例如 root、备份工具、监控探针）。许多线上事故都源于此：以为开启了 read_only 就万无一失，结果 mysqldump 或健康检查脚本悄悄插入了一条记录，破坏了数据一致性。
关键差异：
FLUSH TABLES WITH READ LOCK会阻塞所有写入操作（包括 DML、DDL、事务提交），连 SUPER 用户也无法写入。read_only = ON仅拒绝非 SUPER 用户的写入，并且不会阻塞 DDL（例如DROP TABLE）。read_only修改后不会触发刷盘或清理表缓存，而 FTWRL 会强制刷新脏页、关闭表缓存，确保备份数据的一致性。
解锁前务必确认没有活跃写事务
直接执行 UNLOCK TABLES 并不等于立即恢复写入能力——如果此时仍存在未提交的长事务正在修改数据，FTWRL 释放后，这些事务的提交依然会被阻塞，直到它们自行完成。安全做法是在解锁前进行检查：
- 查询
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING'，重点关注trx_started时间较早的事务。 - 使用
KILL [id]主动终止明显卡住的写事务（例如长时间未提交的UPDATE）。 - 避免在业务高峰期执行 FTWRL，尤其当存在慢查询或大事务时，
close_cached_tables步骤可能卡住数秒甚至更久。
真正危险的不是锁本身，而是你以为它已经释放，但实际上后台仍在等待某个未提交的事务收尾。
