MySQL中通过提高事务隔离级别或加锁解决并发事务问题

1. 提高事务隔离级别

可以设置全局/会话/单个事务的事务隔离级别，事务执行时会向存储引擎请求锁，存储引擎根据事务隔离级别等信息决定如何对数据加锁。

事务隔离级别：读未提交 (READ UNCOMMITTED)、读已提交 (READ COMMITTED)、可重复读 (REPEATABLE READ)、串行化 (SERIALIZABLE)

设置全局事务隔离级别：SET GLOBAL TRANSACTION ISOLATION LEVEL <隔离级别>，需要SUPER或者SESSION_ADMIN权限，不会影响当前正在使用的会话。

设置会话事务隔离级别：SET SESSION TRANSACTION ISOLATION LEVEL <隔离级别>

设置单个事务隔离级别：在事务开始前设置SET TRANSACTION ISOLATION LAVEL <隔离级别>，或直接在START中指定START TRANSACTION ISOLATION LEVEL <隔离级别>

2. 加锁

乐观锁

分析事务场景，如果是读多写少，并发冲突并不频繁发生，那么可以选用 乐观锁 策略。

乐观锁并不直接加锁，而是通过版本号和时间戳等机制来检测冲突。如果检测到冲突，事务会回滚并重试。

版本号和时间戳是实际存在的数据库表的额外字段。可以选择在数据库表设计的时候额外加入version字段，某些数据库 (MySQL等) 也支持自动维护时间戳字段。

悲观锁

如果事务场景是写多读少，并发冲突频繁发生，并且是对数据一致性要求很高的情况，那么可以选用悲观锁。

悲观锁是实际对数据加锁的策略，依赖数据库的锁机制来实现。

根据需要可以加共享锁 (允许多个事务同时读取数据，但不允许修改) 或者排他锁 (组织其他事务对数据的任何读写操作)。

加锁可能产生的弊端

实际上事务隔离级别也是通过锁机制实现的，也是 “提高事务隔离级别”这一方法的可能弊端

  1. 性能降低：锁的限制越多，粒度越高，事务的并发性越低 -> 事务吞吐量下降。
  2. 死锁：高隔离级别下，事务持有锁的时间更长 -> 更容易引发死锁
  3. 系统负载：更多的、限制更大的锁需要更多的系统资源来维护 -> 可能增加系统负载
  4. 响应时间：事务需要等待其他事务释放锁 -> 增加响应时间

补充：MVCC

MVCC通过保存数据的多个版本，允许事务读取旧版本数据，避免加锁冲突。

在InnoDB中，MVCC (多版本并发控制)和锁结合使用，减少锁带来的性能开销。