UNLOCK TABLES 是唯一安全的显式释放方式，执行 FLUSH TABLES WITH READ LOCK 后必须用它解锁，否则锁将持续存在直至连接断开；它仅对当前会话有效，需配对使用且不可省略。
UNLOCK TABLES 是唯一安全的显式释放方式
执行 FLUSH TABLES WITH READ LOCK 后，必须用 UNLOCK TABLES 解锁，不能靠“等一会儿”或“重启客户端”来指望它自动消失。MySQL 不会在超时后自动释放这个锁——它会一直卡着，直到你明确执行 UNLOCK TABLES，或者当前连接断开（但断开不可控，不推荐依赖）。
常见错误现象：SHOW PROCESSLIST 里大量线程状态为 Waiting for table flush；应用写请求持续超时；mysqldump --single-transaction 也卡住（因为 FTWRL 会阻塞 MVCC 快照获取）。
-
UNLOCK TABLES只对当前 session 有效，且必须在同一个连接中执行 - 如果执行
UNLOCK TABLES时报错ERROR 1192 (HY000): Can't execute the given command because you have active locked tables.，说明之前用了LOCK TABLES，得先解锁表再解全局锁 - 不要在脚本里漏掉
UNLOCK TABLES—— 它不是可选步骤，而是强制配对动作
主从环境下必须先停 SQL 线程再加锁
MySQL 8.0 的复制线程（尤其是 Replication_SQL_Thread）在 FTWRL 执行期间仍可能尝试 apply binlog，导致锁被“绕过”或复制中断。这不是 bug，而是设计行为：FTWRL 不会主动 kill 复制线程。
正确顺序是：
- 在从库上先执行
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步骤可能卡住数秒甚至更久
真正危险的不是锁本身，而是你以为它已经释放了，其实后台还在等某个没提交的事务收尾。
