MySQL 8.0全局锁FTWRL的安全释放操作步骤详解

执行 `FLUSH TABLES WITH READ LOCK` 后，解锁的正确操作只有一个：使用 `UNLOCK TABLES`。不要指望“等一会儿”或“重启客户端”能让锁自动消失，MySQL 本身并不提供超时自动释放机制。锁会一直保持，直到你明确执行 `UNLOCK TABLES`，或者当前连接断开（但依赖断连来解锁既不可控也不推荐）。常见的故障场景：`SHOW PROCESSLIST` 中大量线程显示 `Waiting for table flush`；应用写入请求持续超时；甚至 `mysqldump --single-transaction` 也会卡住（因为 FTWRL 会阻塞 MVCC 快照的获取）。

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 步骤可能卡住数秒甚至更久。

真正危险的不是锁本身，而是你以为它已经释放，但实际上后台仍在等待某个未提交的事务收尾。