MySQL的InnoDB存储引擎是目前最常用的存储引擎之一，其并发事务控制机制能够在保证数据一致性的前提下，尽可能提升多事务并发执行的效率，是支撑高并发业务稳定运行的重要基础。
InnoDB并发事务控制的核心目标
并发事务控制主要解决多个事务同时操作同一批数据时可能出现的三类问题：
- 脏读：一个事务读到了另一个事务未提交的数据，若后者回滚，前者读到的数据就是无效的
- 不可重复读：同一个事务内多次读取同一行数据，结果不一致，原因是其他事务修改并提交了该数据
- 幻读：同一个事务内多次执行范围查询，结果集的行数不一致，原因是其他事务插入或删除了符合范围的数据
同时，并发控制还需要平衡一致性和性能，不能为了绝对一致过度降低并发效率。
事务隔离级别
InnoDB支持SQL标准定义的四种事务隔离级别，不同级别对并发问题的解决能力不同：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| READ UNCOMMITTED（读未提交） | 可能 | 可能 | 可能 |
| READ COMMITTED（读已提交） | 不可能 | 可能 | 可能 |
| REPEATABLE READ（可重复读，InnoDB默认） | 不可能 | 不可能 | 可能（InnoDB通过间隙锁基本解决） |
| SERIALIZABLE（串行化） | 不可能 | 不可能 | 不可能 |
可以通过如下语句查看和设置当前会话的隔离级别：
-- 查看当前会话隔离级别 SELECT @@transaction_isolation; -- 设置当前会话隔离级别为读已提交 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
锁机制
锁是InnoDB实现并发控制的基础手段，主要分为以下几类：
行级锁
行级锁是InnoDB的特色，只锁定操作涉及的具体行，并发度更高，分为两种：
- 共享锁（S锁）：事务读取一行数据时加的锁，其他事务可以再加共享锁，但不能加排他锁
- 排他锁（X锁）：事务修改一行数据时加的锁，其他事务不能加任何行锁
行锁的加锁示例如下：
-- 加共享锁，读数据 SELECT * FROM user WHERE id = 1 LOCK IN SHARE MODE; -- 加排他锁，修改数据，或者手动加排他锁 SELECT * FROM user WHERE id = 1 FOR UPDATE; UPDATE user SET name = 'test' WHERE id = 1;
间隙锁
间隙锁是InnoDB在REPEATABLE READ级别下为了解决幻读引入的锁，锁定的是索引记录之间的间隙，防止其他事务往间隙中插入数据。比如执行SELECT * FROM user WHERE id > 10 AND id < 20 FOR UPDATE时，会锁定id在10到20之间的所有间隙，其他事务无法插入id在这个范围的记录。
意向锁
意向锁是表级锁，用来标识一个事务想要对表中的行加哪种类型的行锁，分为意向共享锁（IS）和意向排他锁（IX），作用是提高表级锁和行级锁冲突检查的效率，不需要手动操作，InnoDB会自动添加。
MVCC多版本并发控制
MVCC是InnoDB提升并发读性能的核心机制，它不需要加锁就能实现非阻塞的读操作，核心是通过保存数据的多个历史版本，让不同事务能看到对应版本的数据。
MVCC的实现依赖两个隐藏字段：
- trx_id：最后一次修改该行的事务ID
- roll_pointer：回滚指针，指向该行的上一个历史版本，所有历史版本通过回滚指针形成版本链
每个事务启动时，会生成一个唯一的事务ID，同时获取一个当前活跃事务的快照，读数据时根据快照的规则判断哪个版本的数据对当前事务可见：
- 如果数据版本的trx_id小于当前事务ID，且不在活跃事务列表中，说明该版本是已提交的，可见
- 如果数据版本的trx_id大于等于当前事务ID，或者属于活跃事务，说明该版本是其他未提交事务修改的，不可见，需要沿着版本链找上一个版本
MVCC只在READ COMMITTED和REPEATABLE READ两个隔离级别下生效，READ UNCOMMITTED直接读最新版本，SERIALIZABLE所有读操作都会加锁，不使用MVCC。
常见并发事务问题排查
当出现并发事务相关的问题时，可以通过如下方式排查：
- 查看当前运行的事务：
SELECT * FROM information_schema.innodb_trx;，可以看到事务的状态、开始时间、执行的SQL等信息 - 查看锁等待情况：
SELECT * FROM information_schema.innodb_lock_waits;，可以看到哪些事务在等待锁，被哪个事务阻塞 - 查看当前锁信息：
SELECT * FROM information_schema.innodb_locks;，可以看到当前持有的锁和等待的锁详情
优化建议
为了提升InnoDB并发事务的性能，减少锁冲突，可以参考以下建议：
- 尽量使用短事务，事务执行时间越长，持有锁的时间越久，冲突概率越高
- 操作数据时尽量通过索引定位，避免无索引导致行锁升级为表锁
- 根据业务需求选择合适的隔离级别，不需要绝对一致时可以选择READ COMMITTED，减少间隙锁的使用
- 避免事务中出现交互式操作，比如等待用户输入，减少事务持有锁的时间