悲观锁与乐观锁区别及使用场景
悲观锁（Pessimistic Locking）和乐观锁（Optimistic Locking）是两种处理并发控制的策略，每种策略都有其特定的应用场景和优缺点。它们在 MySQL 中用于管理数据的并发访问和更新，确保数据的一致性和完整性。
1. 悲观锁（Pessimistic Locking）
概念：
- 悲观锁是一种保守的锁策略，它假设会发生冲突，因此在读取或修改数据时会立即锁定数据，以防止其他事务同时修改这些数据。悲观锁的核心思想是“锁住一切”，确保数据在事务执行期间不会被其他事务修改。
实现方式：
- 行级锁：在 MySQL 的 InnoDB 存储引擎中，通过使用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE语句实现。前者用于在读取时锁定数据以进行更新，后者用于读取数据并允许其他事务读取但不修改数据。 - 表级锁：通过
LOCK TABLES语句或LOCK TABLES ... WRITE锁定整个表，从而在事务执行期间防止其他事务对该表进行任何操作。
优点：
- 数据一致性：由于数据在事务期间被锁定，确保了数据的一致性和完整性，避免了并发更新导致的数据冲突。
- 简单易懂：锁定机制明确，容易理解和实现。
缺点：
- 性能开销：锁定的数据会影响并发性能，尤其是在高并发环境下，锁竞争可能导致性能下降。
- 可能导致死锁：多个事务相互等待对方释放锁，可能导致死锁情况。
使用场景：
- 高冲突环境：数据更新冲突的可能性较高，如银行账户余额更新。
- 复杂事务：涉及多个操作的复杂事务，确保操作的原子性和一致性。
2. 乐观锁（Optimistic Locking）
概念：
- 乐观锁是一种假设冲突不会发生的锁策略，它在事务开始时不立即锁定数据，而是在提交时检查数据是否被其他事务修改。如果数据在事务期间被修改，则提交操作会失败，事务需要重新尝试或进行补救。
实现方式：
- 版本号：在表中添加一个版本号字段，每次更新数据时，版本号都会递增。事务在提交时检查版本号是否匹配，如果不匹配则回滚或重试。
- 时间戳：在表中添加一个时间戳字段，每次更新时记录时间戳。事务在提交时检查时间戳是否匹配，确保数据在提交期间没有被修改。
优点：
- 减少锁竞争：由于数据在事务期间没有被锁定，减少了锁竞争，提高了并发性能。
- 避免死锁：乐观锁不涉及锁的获取和释放，因此避免了死锁问题。
缺点：
- 处理复杂性：事务需要检查数据版本或时间戳，如果发生冲突，事务可能需要重新执行或处理失败的情况。
- 不适用于高冲突环境：在高冲突环境下，重试操作的开销可能较大。
使用场景：
- 低冲突环境：数据更新冲突的可能性较低，如用户信息的更新。
- 高并发环境：需要高并发性能的应用，如 Web 应用的会话管理。
总结
- 悲观锁：在事务执行期间锁定数据，以确保一致性和完整性，适用于高冲突或复杂事务场景。缺点是可能导致性能下降和死锁。
- 乐观锁：假设数据冲突不会发生，减少了锁的竞争，适用于低冲突环境或需要高并发性能的场景。缺点是处理冲突和重试可能增加复杂性。
根据应用场景和业务需求选择合适的锁策略，可以有效地管理并发访问和数据一致性。