MySQL锁机制详解：从乐观锁到悲观锁

MySQL锁机制详解：从乐观锁到悲观锁

前言

在高并发的数据库应用场景中，锁机制是保证数据一致性和完整性的核心手段。MySQL提供了多种锁机制来应对不同的并发场景。本文将深入探讨MySQL中的各种锁机制，包括乐观锁、悲观锁以及MySQL内部的各种锁类型。

一、锁的分类概览

MySQL的锁机制可以从不同维度进行分类：

• 按锁的粒度：表级锁、行级锁、页级锁
• 按锁的属性：共享锁（S锁）、排他锁（X锁）
• 按锁的策略：乐观锁、悲观锁
• 按锁的算法：记录锁、间隙锁、临键锁

二、乐观锁（Optimistic Locking）

2.1 概念

乐观锁是一种乐观思想的体现，它假设数据一般情况下不会造成冲突，所以在数据进行提交更新时才会对数据的冲突与否进行检测。如果发现冲突了，则返回错误信息，让用户决定如何去做。

2.2 实现方式

方式一：版本号机制

-- 创建表时添加版本号字段
CREATE TABLE product (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    stock INT,
    version INT DEFAULT 0
);

-- 查询时获取版本号
SELECT id, name, stock, version FROM product WHERE id = 1;

-- 更新时检查版本号
UPDATE product
SET stock = stock - 1, version = version + 1
WHERE id = 1 AND version = 100;

-- 检查影响行数，如果为0则表示版本冲突

方式二：时间戳机制

-- 使用更新时间作为版本标识
CREATE TABLE product (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    stock INT,
    update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

-- 查询时获取更新时间
SELECT id, name, stock, update_time FROM product WHERE id = 1;

-- 更新时检查时间戳
UPDATE product
SET stock = stock - 1
WHERE id = 1 AND update_time = '2024-01-01 10:00:00';

2.3 优缺点

优点：

• 不会产生锁等待，提高系统吞吐量
• 适合读多写少的场景
• 避免死锁问题

缺点：

• 更新冲突时需要重试，增加了应用层复杂度
• 高并发写场景下，冲突频繁导致大量重试

2.4 适用场景

• 读操作远多于写操作
• 冲突较少的业务场景
• 对响应时间要求较高的场景

三、悲观锁（Pessimistic Locking）

3.1 概念

悲观锁是一种悲观思想的体现，它总是假设最坏的情况，认为数据在被访问时很可能会被其他事务修改，因此在整个数据处理过程中都会对数据加锁。

3.2 实现方式

共享锁（S锁，读锁）

-- 使用SELECT ... LOCK IN SHARE MODE（MySQL 8.0之前）
-- 或 SELECT ... FOR SHARE（MySQL 8.0+）
SELECT * FROM product WHERE id = 1 LOCK IN SHARE MODE;

-- MySQL 8.0+ 推荐语法
SELECT * FROM product WHERE id = 1 FOR SHARE;

多个事务可以同时持有共享锁，但任何事务都不能获取排他锁。

排他锁（X锁，写锁）

-- 使用SELECT ... FOR UPDATE
BEGIN;
SELECT * FROM product WHERE id = 1 FOR UPDATE;
-- 执行业务逻辑
UPDATE product SET stock = stock - 1 WHERE id = 1;
COMMIT;

一旦事务获取了排他锁，其他事务既不能获取共享锁，也不能获取排他锁。

3.3 优缺点

优点：

• 确保数据操作的安全性
• 适合写多读少的场景
• 能够彻底避免数据冲突

缺点：

• 并发性能较差，可能产生锁等待
• 可能导致死锁
• 降低系统吞吐量

3.4 适用场景

• 写操作频繁的场景
• 对数据一致性要求极高的场景
• 冲突概率较高的业务

四、MySQL内部锁机制

4.1 表级锁（Table Lock）

表级锁是MySQL中粒度最大的锁，对整张表加锁。

表读锁

LOCK TABLES product READ;
-- 执行读操作
SELECT * FROM product;
UNLOCK TABLES;

表写锁

LOCK TABLES product WRITE;
-- 执行写操作
UPDATE product SET stock = 100 WHERE id = 1;
UNLOCK TABLES;

特点：

• 开销小，加锁快
• 不会出现死锁
• 锁粒度大，并发度低
• MyISAM存储引擎主要使用表级锁

4.2 行级锁（Row Lock）

行级锁是MySQL中粒度最小的锁，只针对当前操作的行进行加锁。

记录锁（Record Lock）

锁定索引记录，防止其他事务对该记录进行修改或删除。

-- 通过主键或唯一索引精确匹配时使用记录锁
SELECT * FROM product WHERE id = 1 FOR UPDATE;

间隙锁（Gap Lock）

锁定索引记录之间的间隙，防止其他事务在间隙中插入数据。

-- 范围查询时可能产生间隙锁
SELECT * FROM product WHERE id > 5 AND id < 10 FOR UPDATE;

间隙锁的作用：

• 防止幻读（Phantom Read）
• 仅在可重复读（REPEATABLE READ）隔离级别下生效

临键锁（Next-Key Lock）

临键锁是记录锁和间隙锁的组合，锁定一个范围，并且锁定记录本身。

-- InnoDB默认使用临键锁
-- 假设有索引值：1, 5, 10, 15
-- 执行以下语句会锁定(5, 10]
SELECT * FROM product WHERE id = 10 FOR UPDATE;

特点：

• InnoDB默认的行锁算法
• 解决幻读问题
• 在可重复读隔离级别下使用

4.3 意向锁（Intention Lock）

意向锁是表级锁，用于表明事务即将对表中的行加什么类型的锁。

意向共享锁（IS）

-- 事务想要获取表中某些行的共享锁前，必须先获取IS锁
SELECT * FROM product WHERE id = 1 LOCK IN SHARE MODE;

意向排他锁（IX）

-- 事务想要获取表中某些行的排他锁前，必须先获取IX锁
SELECT * FROM product WHERE id = 1 FOR UPDATE;

作用：

• 简化表锁与行锁的冲突判断
• 提高加表锁的效率

4.4 自增锁（AUTO-INC Lock）

自增锁是一种特殊的表级锁，用于保证自增列的唯一性。

CREATE TABLE orders (
    id INT AUTO_INCREMENT PRIMARY KEY,
    order_no VARCHAR(50)
);

-- 插入时自动获取自增锁
INSERT INTO orders (order_no) VALUES ('ORDER001');

特点：

• 语句执行完成后立即释放，不用等事务提交
• 从MySQL 5.1.22开始，可通过innodb_autoinc_lock_mode配置

五、死锁问题

5.1 死锁产生的条件

1. 互斥条件：资源不能被共享
2. 请求与保持条件：已获得资源的进程请求新资源
3. 不剥夺条件：已获得的资源不能被强制剥夺
4. 循环等待条件：存在进程资源循环等待链

5.2 死锁示例

-- 事务1
BEGIN;
UPDATE product SET stock = 100 WHERE id = 1;
-- 等待...
UPDATE product SET stock = 200 WHERE id = 2;
COMMIT;

-- 事务2
BEGIN;
UPDATE product SET stock = 300 WHERE id = 2;
-- 等待...
UPDATE product SET stock = 400 WHERE id = 1;
COMMIT;

5.3 死锁预防和处理

预防策略：

1. 按顺序访问资源

-- 始终按照id顺序更新
UPDATE product SET stock = stock - 1 WHERE id IN (1, 2, 3) ORDER BY id;

2. 缩短事务持有锁的时间

-- 尽快提交事务
BEGIN;
UPDATE product SET stock = stock - 1 WHERE id = 1;
COMMIT;  -- 及时提交

3. 使用合理的索引

-- 确保WHERE条件使用索引，减少锁范围
CREATE INDEX idx_product_name ON product(name);

MySQL死锁检测：

-- 查看最近的死锁日志
SHOW ENGINE INNODB STATUS;

MySQL的InnoDB引擎会自动检测死锁，并回滚其中一个事务。

六、锁的性能优化建议

6.1 减小锁粒度

-- 不好的做法：锁定整张表
LOCK TABLES product WRITE;

-- 好的做法：只锁定需要的行
SELECT * FROM product WHERE id = 1 FOR UPDATE;

6.2 使用合适的索引

-- 确保WHERE条件有索引，避免全表扫描导致锁表
CREATE INDEX idx_status ON orders(status);

-- 使用索引查询，只锁定命中的行
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;

6.3 控制事务大小

-- 不好的做法：一个事务处理太多数据
BEGIN;
UPDATE product SET stock = stock - 1 WHERE category = 'electronics';  -- 可能影响数千行
-- 其他大量操作...
COMMIT;

-- 好的做法：分批处理
BEGIN;
UPDATE product SET stock = stock - 1 WHERE category = 'electronics' AND id BETWEEN 1 AND 100;
COMMIT;

6.4 选择合适的隔离级别

-- 如果不需要防止幻读，可以使用读已提交隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 查看当前隔离级别
SELECT @@transaction_isolation;

6.5 避免长事务

-- 不好的做法
BEGIN;
SELECT * FROM product WHERE id = 1 FOR UPDATE;
-- 执行大量业务逻辑，耗时很长...
sleep(10);
UPDATE product SET stock = stock - 1 WHERE id = 1;
COMMIT;

-- 好的做法：先查询，再快速更新
SELECT * FROM product WHERE id = 1;
-- 执行业务逻辑...
BEGIN;
UPDATE product SET stock = stock - 1 WHERE id = 1 AND version = 100;
COMMIT;

七、实际应用场景示例

场景1：库存扣减（使用悲观锁）

-- 开始事务
BEGIN;

-- 锁定库存记录
SELECT stock FROM product WHERE id = 1001 FOR UPDATE;

-- 检查库存
-- 假设查询结果stock = 50

-- 扣减库存
UPDATE product SET stock = stock - 1 WHERE id = 1001;

-- 创建订单
INSERT INTO orders (product_id, quantity) VALUES (1001, 1);

-- 提交事务
COMMIT;

场景2：秒杀系统（使用乐观锁）

-- 查询商品信息和版本号
SELECT id, stock, version FROM product WHERE id = 1001;
-- 假设返回：stock=100, version=1

-- 尝试扣减库存
UPDATE product
SET stock = stock - 1, version = version + 1
WHERE id = 1001 AND version = 1 AND stock > 0;

-- 检查affected_rows
-- 如果为0，表示更新失败，需要重试或返回"已售罄"
-- 如果为1，表示更新成功，继续创建订单

场景3：账户转账（使用悲观锁）

BEGIN;

-- 锁定转出账户和转入账户（按id顺序加锁，避免死锁）
SELECT balance FROM account WHERE id = 100 FOR UPDATE;  -- 转出账户
SELECT balance FROM account WHERE id = 200 FOR UPDATE;  -- 转入账户

-- 检查转出账户余额
-- 假设balance = 1000，转账金额 = 500

-- 扣减转出账户
UPDATE account SET balance = balance - 500 WHERE id = 100;

-- 增加转入账户
UPDATE account SET balance = balance + 500 WHERE id = 200;

-- 记录转账日志
INSERT INTO transfer_log (from_account, to_account, amount) VALUES (100, 200, 500);

COMMIT;

八、总结

锁机制选择指南

场景	推荐锁类型	理由
读多写少	乐观锁	减少锁等待，提高并发性能
写多读少	悲观锁	避免频繁的冲突重试
对数据一致性要求极高	悲观锁	彻底避免并发冲突
库存扣减	悲观锁	确保库存准确性
秒杀系统	乐观锁	减少锁竞争，提高吞吐量
金融交易	悲观锁	确保资金安全

关键要点

1. 乐观锁适合冲突少的场景，通过版本号或时间戳实现
2. 悲观锁 适合冲突多的场景，使用FOR UPDATE或LOCK IN SHARE MODE
3. 行级锁并发性能好，但可能产生死锁
4. 表级锁开销小，但并发度低
5. 间隙锁和临键锁用于防止幻读
6. 合理使用索引可以减小锁的范围
7. 控制事务大小和执行时间可以提高并发性能
8. 按顺序访问资源可以预防死锁

参考资料

• MySQL官方文档：InnoDB Locking
• 《高性能MySQL》
• 《MySQL技术内幕：InnoDB存储引擎》

---

本文详细介绍了MySQL的各种锁机制，希望能帮助你在实际开发中选择合适的锁策略，构建高并发、高性能的数据库应用。