【面试干货】数据库乐观锁，悲观锁的区别，怎么实现

1、乐观锁，悲观锁的区别

1. 悲观锁（Pessimistic Lock）
   
   定义： 每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞挂起直到它拿到锁。
   
   实现： 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在做操作之前先上锁。
   
   特点： 适用于写操作频繁的场景，但可能会降低并发性能，因为上锁会阻塞其他操作的进行。

示例代码（伪代码）：

-- 悲观锁示例（以行锁为例）  
SELECT * FROM table_name WHERE id = 1 FOR UPDATE;  -- 对id为1的行加锁
1
2

2. 乐观锁（Optimistic Lock）
   
   定义： 每次去拿数据的时候都认为别人不会修改数据，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
   
   实现：版本号机制 （如：为数据表增加一个版本号字段，在更新数据时判断版本号是否变化）或者时间戳机制（使用数据的最后更新时间戳，在更新时判断时间戳是否发生变化）是常见的乐观锁实现方式。
   
   特点： 适用于多读少写的场景，可以提高系统的整体吞吐量。但如果冲突频繁，上层应用会不断重试，降低性能。

示例代码（伪代码）:

-- 乐观锁示例（以版本号为例）  
UPDATE table_name SET column1 = value1, version = version + 1 WHERE id = 1 AND versio
1
2

old_version 是之前读取到的版本号，如果更新操作影响的行数为0，则表示在此期间有其他事务已经修改了数据，需要重试。

2、总结

选择：

1、根据实际应用场景选择使用悲观锁还是乐观锁。 如果写操作较少，且希望提高系统吞吐量，可以考虑使用乐观锁；

2、如果写操作频繁，且希望减少数据冲突，可以考虑使用悲观锁。

注意： 在使用乐观锁时，需要合理设置重试次数和重试间隔，避免频繁重试导致性能下降。同时，需要确保在更新数据时能够正确判断数据是否被其他事务修改过。