MySQL全局锁核心目标是保障全库备份一致性，通过FTWRL加全局读锁使实例只读，阻塞写和DDL；但主库慎用，InnoDB推荐--single-transaction配合MVCC实现无锁一致性备份，MyISAM等非事务引擎则必须依赖锁。

MySQL 全局锁机制的核心目标是保证全库备份时的数据一致性，但它不是唯一方案，也不是推荐在生产主库上直接使用的方案。是否加锁、怎么加锁，取决于存储引擎类型、业务容忍度和备份工具配置。

全局锁怎么用：FTWRL 与释放时机

全局读锁通过 FLUSH TABLES WITH READ LOCK（简称 FTWRL）触发，执行后整个实例进入只读状态：

• 所有表的写操作（INSERT/UPDATE/DELETE/ALTER）立即被阻塞
• SELECT 可正常执行，适合配合逻辑备份工具导出数据
• 锁由 UNLOCK TABLES 显式释放；若加锁会话异常断开，MySQL 自动释放
• 不建议在高并发主库上执行，否则订单、登录等写请求全部挂起

InnoDB 下更优解：–single-transaction 参数

对于默认的 InnoDB 引擎，无需全局锁也能实现一致性备份，关键在于利用 MVCC 的快照读能力：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• mysqldump 加上 --single-transaction 参数，会在备份开始时启动一个 REPEATABLE READ 事务
• 该事务通过 Read View 获取“一致性视图”，后续所有 SELECT 都基于同一时间点的数据快照
• 备份过程中业务写入不受影响，主库持续可用
• 注意：此方式不能防止备份期间的 DDL 操作（如 DROP TABLE），需额外规避

MyISAM 或混合引擎场景：锁表仍是刚需

MyISAM 不支持事务和 MVCC，无法使用 –single-transaction，此时必须依赖锁来冻结数据状态：

• 可选 --lock-all-tables（等价于 FTWRL）或 --lock-tables（按库逐个锁表）
• 锁期间所有写操作暂停，适合夜间低峰期或从库备份
• 若在从库执行，会导致 SQL 线程暂停应用 binlog，加剧主从延迟
• 备份完成后锁自动释放，无需手动 UNLOCK TABLES

真正的一致性保障：不止靠锁

锁只是手段之一，完整的一致性方案还需结合其他机制：

• GTID + MASTER_AUTO_POSITION：确保主从切换或恢复时精准定位同步位点
• binlog 位置记录（如 mysqldump 的 --master-data=2）：把备份时刻的 binlog 文件名与偏移量写入 dump 文件，便于后续增量恢复
• Redo Log 与 Undo Log：保障单机崩溃后事务原子性和数据可恢复性，是底层一致性基石
• 双写缓冲（Double Write Buffer）：防止页写入中断导致数据页损坏，避免物理层面不一致