在数据库操作中，锁机制是确保数据一致性和完整性的重要手段，悲观锁是一种常见的并发控制策略，它假设在数据处理过程中一定会发生冲突，因此在操作数据前先对数据加锁，阻止其他事务同时修改，本文将详细介绍如何在数据库中实现悲观锁，包括其原理、适用场景、具体实现方法及注意事项。
悲观锁的原理与适用场景
悲观锁的核心思想是“先锁定，再操作”，即在事务开始时对需要操作的数据加锁，直到事务提交或回滚后才释放锁，这种机制可以有效防止并发修改导致的数据不一致问题，悲观锁适用于读多写少、对数据一致性要求极高的场景，例如金融交易、库存扣减等，在这些场景中，即使并发冲突的概率较低，一旦发生可能造成严重后果,因此使用悲观锁更为稳妥。
数据库中实现悲观锁的方法
在关系型数据库中,悲观锁通常通过以下几种方式实现：
使用SELECT FOR UPDATE语句
这是最常见的悲观锁实现方式，在查询数据时，通过SELECT ... FOR UPDATE语句锁定选中的行，其他事务无法对这些行进行修改或加锁,直到当前事务结束。
BEGIN; SELECT * FROM products WHERE id = 1 FOR UPDATE; -- 执行业务逻辑，如库存扣减 UPDATE products SET stock = stock - 1 WHERE id = 1; COMMIT;
上述代码中，FOR UPDATE会锁定id=1的行,确保其他事务无法同时修改该行数据。
使用排他锁（EXCLUSIVE LOCK）
部分数据库支持直接使用LOCK TABLE语句对整张表加锁，
BEGIN; LOCK TABLE products IN EXCLUSIVE MODE; -- 执行业务逻辑 COMMIT;
这种方式会锁定整张表，并发性能较低,通常在需要批量操作时使用。
基于版本号的乐观锁与悲观锁结合
虽然乐观锁和悲观锁是两种不同的策略，但有时可以结合使用，在查询数据时先读取版本号，并在更新时检查版本号是否变化，同时结合FOR UPDATE锁定数据,进一步增强并发控制。
悲观锁的注意事项
使用悲观锁时需注意以下几点：
锁的粒度
锁的粒度越细，并发性能越好，应尽量锁定最小必要的数据范围，例如通过索引锁定特定行,而非整张表。
死锁问题
悲观锁可能导致死锁，例如两个事务互相等待对方释放锁，为避免死锁,可以采取以下措施：
- 按固定顺序访问数据；
- 设置锁的超时时间；
- 数据库自动检测并回滚死锁事务。
事务隔离级别
事务的隔离级别会影响悲观锁的行为，在READ COMMITTED隔离级别下，锁可能提前释放，而在SERIALIZABLE级别下，锁会持续到事务结束,应根据业务需求选择合适的隔离级别。
性能影响
悲观锁会降低并发性能，尤其是在高并发场景下，需权衡数据一致性与性能需求,避免过度使用悲观锁。
实际应用案例
以电商库存扣减为例，假设需要确保商品库存不被超卖,可以使用以下步骤实现悲观锁：
- 开启事务；
- 查询商品信息并加锁：
SELECT stock FROM products WHERE id = 1 FOR UPDATE； - 检查库存是否充足，若充足则扣减库存：
UPDATE products SET stock = stock - 1 WHERE id = 1； - 提交事务,释放锁。
通过这种方式，可以确保在库存扣减过程中,其他事务无法同时修改该商品的库存数据。
相关问答FAQs
Q1: 悲观锁和乐观锁有什么区别？
A1: 悲观锁假设冲突一定会发生，因此在操作前先加锁，适合高冲突场景；乐观锁假设冲突较少，只在提交时检查数据是否被修改，适合低冲突场景，悲观锁并发性能较低，但一致性更强；乐观锁并发性能较高,但可能需要重试机制。
Q2: 如何避免悲观锁导致的死锁？
A2: 避免死锁的方法包括：按固定顺序访问数据（如先锁定A表再锁定B表）；设置锁的超时时间（如MySQL的innodb_lock_wait_timeout参数）；让数据库自动检测并回滚死锁事务（如InnoDB的自动死锁检测机制），尽量减少事务的持有时间,也能降低死锁概率。