MySQL全局锁指的是什么
数据库设计的初衷是处理并发问题的，作为多用户共享的资源，当出现并发访问时，数据库需要合理地控制资源的访问规则。而锁就是用来实现这个访问规则的重要数据结构。我们先来贴一个锁的大概分类的图根据加锁的范围，MySQL里面的锁大致可以分为全局锁、表锁、行锁。我们主要先来学习这几种锁，这篇我们学习全局锁。全局锁全局锁就是对整个数据库加锁。当我们对数据库加了读锁之后，其他任何的请求都不能对数据库加写锁了，当我们对数据库加了写锁之后，后续其他任何的请求都不能对数据库加读锁和写锁了。FTWRLMySQL提供了一个加全局读
数据库设计的初衷是处理并发问题的，作为多用户共享的资源，当出现并发访问时，数据库需要合理地控制资源的访问规则。而锁就是用来实现这个访问规则的重要数据结构。
我们先来贴一个锁的大概分类的图
根据加锁的范围，MySQL 里面的锁大致可以分为全局锁、表锁、行锁。我们主要先来学习这几种锁，这篇我们学习全局锁。
全局锁
全局锁就是对整个数据库加锁。当我们对数据库加了读锁之后，其他任何的请求都不能对数据库加写锁了，当我们对数据库加了写锁之后，后续其他任何的请求都不能对数据库加读锁和写锁了。
FTWRL
MySQL 提供了一个加全局读锁的方法，Flush tables with read lock (FTWRL)。当我们需要让整个库处于只读状态时，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。
全局锁的使用场景
全局锁的使用场景：做全库的逻辑备份。逻辑备份也就是把整个库的每个表都 select 出来存成文本。也就是全局锁只有在进行主从备份数据或者导入导出数据的时候才会使用到。
那么为什么需要全局锁呢？
因为我们在做数据备份或者导入导出数据的时候，如果在这个期间还可以同时进行数据的增删改，那么就会出现数据不一致的问题。
以前有一种做法是通过上面提到的 FTWRL 确保在备份的时候不会有其他线程对数据库做更新，注意：这里备份过程中整个库都是完全处于只读状态。
因为全局锁是面向这个数据库的，所以加全局锁听起来很危险：
如果我们在主库上备份，在备份期间都不能执行更新，也就是基本上全部业务暂停。
如果我们在从库上备份，在备份期间主库同步过来的 binlog 从库都不能执行，也就是会导致主从延迟，数据不一致。
如何避免加锁
既然加全局锁影响这么大，我们能不能避免加锁呢？
通过上面的介绍，我们知道加锁是为了解决数据不一致问题。那么是不是只要我们能解决数据不一致的问题，就可以不用加全局锁了。有这样一个思路：如果我们在开始进行数据备份的时候，记录一个操作日志，备份过程中不加锁允许对数据库的增删改查，而在备份过程中，增删改查的操作记录都记到一个日志文件里，等我们备份完成后，再把这段时间日志文件里的操作都执行一遍。这样就能保证备份前后数据的一致性了。
总结，不加锁的话，备份得到数据和主数据不是一个逻辑时间点，这个视图是逻辑不一致的。如果保证逻辑时间点一致即逻辑视图一致就能保证数据一致，由此我们就想到了我们之前学过的事务隔离级别，可重复复读的隔离级别下开启一个事务就是一个一致性视图。
在 MySQL 的默认引擎 InnoDB 里有一个机制可以保证数据一致性。InnoDB 引擎中有数据快照版本的功能，这个功能叫 MVCC，因为 MVCC 保留了历史版本的快照，每个快照都对应一个事务版本号，而在我们备份数据的时候会申请一个事务版本号，在读取数据的时候，只需要读取比自己事务版本号小的数据即可。
–single-transaction 命令加锁
官方自带的逻辑备份工具是 mysqldump。当 mysqldump 使用参数 –single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。
--single-transaction 参数的作用，设置事务的隔离级别为可重复读，即 REPEATABLE READ，这样能保证在一个事务中所有相同的查询读取到同样的数据，也就大概保证了在 dump 期间，如果其他 InnoDB 引擎的线程修改了表的数据并提交，对该 dump 线程的数据并无影响。
并且设置 WITH CONSISTENT SNAPSHOT 为快照级别。设想一下，如果只是可重复读，那么在事务开始时还没 dump 数据时，这时其他线程修改并提交了数据，那么这时第一次查询得到的结果是其他线程提交后的结果，而 WITH CONSISTENT SNAPSHOT 能够保证在事务开启的时候，第一次查询的结果就是事务开始时的数据 A，即使这时其他线程将其数据修改为 B，查的结果依然是 A。
single-transaction方法只适用于所有的表使用事务引擎的库。在 mysqldump 过程中，加了--single-transaction 就能保证 InnoDB 的数据是完全一致的，对于MyISAM这种不支持事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就破坏了备份的一致性。这时候就还是需要全局锁的，所以我们就还是需要使用 FTWRL 命令的。
只读设置
我们可能还会有这样一个疑问，既然要全库只读，我们为什么不适用 set global readonly = true 的方式呢？
确实 readonly 方式也可以让全库进入只读状态，但还是会建议用 FTWRL 方式，主要有两个原因：
在有些系统，readonly 的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大。
在异常处理机制上有差异。如果执行 FTWRL 命令之后由于客户端发生异常断开，那么 MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。
而将整个库设置为 readonly 之后，如果客户端发生异常，则数据库就会一直保持 readonly 状态，这样会导致整个库长时间处于不可写状态，风险较高。
详解Navicat导入数据库的标准步骤，涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误，提供具体的设置方法与修复建议，确保数据迁移准确无误。
深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发，详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例，指导开发者如何根据字段稳定性与业务语义合理选择约束类型，避免设计误区。
刚开始设计关系型数据库？了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主，结合用户订单场景，清晰展示如何防止脏数据并处理常见约束冲突。
深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比，展示如何识别长事务持锁、分析锁等待链，并提供短事务提交、异常清理及批量处理的最佳实践，确保数据库连接与锁资源及时释放。
后端开发者在维护数据库时，常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT，往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法，帮助你在生产环境安全完成结构变更。
针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异，以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果，并排查因 JOIN 连接导致的统计数据异常，提升报表准确性。
本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历，再到CLOSE关闭与DEALLOCATE/Handler清理，解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标，避免资源泄漏，适用于需要进行数据库存储过程开发或跨平台迁移的开发者。
深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例，展示匹配行保留与NULL补位机制，重点讲解ON与WHERE子句中放置右表过滤条件的不同后果，提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。
深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景，讲解如何定义单列范围与多列逻辑约束，分析 NULL 值对布尔条件的影响，并提供修改已有表结构时的安全操作建议，帮助开发者构建更健壮的数据完整性防线。
后端开发中，如何正确使用 SQL 外键约束来维护订单与明细表的关系？本文通过 PostgreSQL 示例，深入讲解外键的创建语法、插入顺序要求，以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制，助你构建健壮的数据库结构。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
