MySQL的各种锁(表锁，行锁，悲观锁，乐观锁，间隙锁，死锁) 怎么用？

云游道人 2025-02-02 442 阅读 0评论

MySQL 提供了多种锁机制来控制并发访问数据的方式，确保多个客户端可以同时读取和修改数据而不会产生不一致的结果。常见的锁类型包括表锁、行锁、悲观锁、乐观锁、间隙锁 和死锁等。每种锁有不同的实现方式、使用场景和影响性能的特性。下面我们详细分析每种锁类型。

1. 表锁（Table Lock）

表锁是最简单的一种锁，它锁定整张表，使得其他事务不能修改该表的任何数据。表锁一般是在执行 LOCK TABLES 或使用某些特定的存储引擎（如 MyISAM）时出现的。

特点：

锁粒度：锁住整个表。
性能影响：锁粒度大，容易导致性能瓶颈，尤其是在高并发的情况下。
适用场景：当事务不涉及大范围并发时，使用表锁较为简单且高效。例如批量更新或读取不频繁的表。

SQL 示例：

LOCK TABLES users WRITE;  -- 锁定表
SELECT * FROM users;      -- 执行查询
UNLOCK TABLES;            -- 解锁表

2. 行锁（Row Lock）

行锁是指只锁定表中的某一行数据，而不是整张表。这是 InnoDB 存储引擎使用的锁方式，行锁可以减少锁的冲突，提高并发性。

特点：

锁粒度：锁住特定的一行数据。
性能影响：行锁的粒度比表锁小，性能较好，尤其在并发事务较多的情况下。
适用场景：在高并发环境中，行锁可以有效避免表级锁带来的性能瓶颈。例如，更新特定用户的数据时，只锁定该行数据。

SQL 示例：

-- 在 InnoDB 存储引擎下，行锁通过 SELECT ... FOR UPDATE 实现
BEGIN;
SELECT * FROM users WHERE user_id = 1 FOR UPDATE;  -- 锁定该行
UPDATE users SET balance = balance - 100 WHERE user_id = 1;
COMMIT;

3. 悲观锁（Pessimistic Lock）

悲观锁是一种防御性很强的锁，它认为并发冲突是常见的，因此在访问数据时会主动加锁，直到事务完成后才释放锁。悲观锁通常通过 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 来实现。

特点：

锁粒度：可以是行锁或表锁，具体取决于操作。
性能影响：悲观锁的性能相对较差，因为每次访问数据时都要加锁并保持锁直到事务完成，容易导致阻塞。
适用场景：适用于并发冲突频繁且需要保证数据一致性的场景，如银行账户转账等。

SQL 示例：

-- 使用悲观锁，确保行被锁定
BEGIN;
SELECT * FROM accounts WHERE account_id = 1 FOR UPDATE;  -- 悲观锁
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
COMMIT;

4. 乐观锁（Optimistic Lock）

乐观锁是一种假设并发冲突较少的锁机制，它在更新数据之前并不立即加锁，而是读取数据时保存数据的版本号或时间戳，在提交更新时会检查版本号或时间戳是否发生变化。如果发生变化，则认为数据已被其他事务修改，事务将回滚或重新执行。

特点：

锁粒度：乐观锁不真正加锁，只是在更新时进行版本号或时间戳检查。
性能影响：性能较高，适用于读多写少的场景。
适用场景：适用于高并发且修改较少的环境，如商品库存更新等。

实现方法：

通常通过在表中增加 version 或 timestamp 字段来实现。

-- 假设表 users 有一个 `version` 字段来实现乐观锁
UPDATE users
SET balance = balance - 100, version = version + 1
WHERE user_id = 1 AND version = 2;  -- 检查 version 是否匹配

5. 间隙锁（Gap Lock）

间隙锁是一种锁定查询范围的锁，它锁定一个范围（如某个区间的记录），但不锁定具体的行。间隙锁通常用于 InnoDB 在执行 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 时，尤其是在进行范围查询时。

特点：

锁粒度：锁定一个区间的范围，但不包括区间的边界行。
性能影响：由于锁定范围而不是具体行，可能会导致死锁或锁竞争的情况，性能较差。
适用场景：适用于需要保证范围内所有记录被保护的场景。

SQL 示例：

BEGIN;
-- 锁定 user_id 在 10 和 20 之间的记录，但不包括 10 和 20
SELECT * FROM users WHERE user_id BETWEEN 10 AND 20 FOR UPDATE;
COMMIT;

6. 死锁（Deadlock）

死锁是一种多个事务在执行过程中，因竞争资源而互相等待，导致每个事务都无法继续执行的情况。死锁通常发生在多个事务持有不同资源锁且相互等待对方释放锁的情况下。

特点：

死锁发生条件：多个事务持有互相需要的锁，并且都无法继续执行，形成闭环。
性能影响：死锁会导致某些事务无法继续执行，必须回滚其中一个事务来打破死锁。
适用场景：死锁通常发生在复杂的事务操作中，特别是在并发高且事务相互依赖的情况下。

SQL 示例（模拟死锁）：

-- 事务 1
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;  -- 锁住 account 1
-- 等待 事务 2 完成
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT;

-- 事务 2
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 2;  -- 锁住 account 2
-- 等待 事务 1 完成
UPDATE accounts SET balance = balance + 100 WHERE account_id = 1;
COMMIT;