数据库原理及 MySQL 应用 | 并发控制
简介： 无论何时,只要有多个查询需要在同一时刻修改数据,都会产生并发控制问题，MySQL 通过多版本并发控制和加锁实现并发控制。
无论何时,只要有多个查询需要在同一时刻修改数据,都会产生并发控制问题，MySQL 通过多版本并发控制和加锁实现并发控制。
多用户并发执行事务访问同一个数据库时，可能引发脏写、脏读、不可重复读、幻读等一致性问题。并发事务访问相同记录的情况，可分为以下三种。
- 读-读
即多个并发事务相继读取相同的记录。这种情况是允许的，因为读取操作不会修改记录的内容。
- 写-写
即多个并发事务相继对相同的记录进行修改。这种情况下会发生“脏写”现象，任何一种隔离级别都不允许这种现象发生。此时，需要通过锁机制，使这些未提交的并发事务排队依次执行。
当一个事务想对这条记录进行改动时，需要先加锁，加锁成功事务才能继续操作；若加锁失败事务需要等待。
- 读-写或写-读
即一个事务在进行读操作，另一个事务在进行写操作。这种情况下可能会出现脏读、不可重复读、幻读的现象。MySQL 采用了以下两种解决方案。
(1) 读操作使用多版本并发控制(MVCC)，写操作进行加锁。
(2) 读操作和写操作都采用加锁的方式。
采用 MVCC 方式，读操作和写操作彼此并不冲突，性能更高。而采用加锁方式，读操作和写操作需要排队执行，从而影响性能。
一般情况下，可以采用 MVCC 来解决读操作和写操作并发执行的问题，但一些业务场景要求每次都必须读取记录的最新版，不允许读取记录的旧版本，这种情况下就只能采用加锁的方式了。
01、MVCC
MVCC(Multi-Version Concurrency Control，多版本并发控制)是一种用来解决读-写冲突的无锁并发控制机制，在数据库中用来控制并发执行的事务，使事务隔离进行。其本质是为了在进行读操作时代替加锁，减少加锁带来的负担。写操作使用记录的最新版本，读操作使用记录的历史版本，这样使不同事务的读-写、写-读操作可以并发执行，提高数据库并发性能。
MVCC 是通过保存数据在某个时间点的快照(Read View)来进行控制的。同一个数据记录可以拥有多个不同的版本，并通过聚簇索引记录和 undo 日志的 roll_pointer 属性串联成一个记录的版本链，通过生成的快照来判断记录的某个版本的可见性。在查询时通过添加相对应的约束条件，获取用户想要的对应版本的数据。
MVCC 只适用于 MySQL 隔离级别中的 READ COMMITTED(提交读)和 REPEATABLE READ(可重复读)级别。MVCC 其实就是使用这两种隔离级别的事务执行普通的读操作时访问记录的版本链的过程。
1. MVCC 与四种隔离级别的关系
1) READ UNCOMMITTED(未提交读)
由于存在脏读，即能读到未提交事务的数据行，所以不适用 MVCC。
2) SERIALIZABLE(序列化)
由于 InnoDB 会对所涉及的表加锁，并非行级锁，不存在行的版本控制问题，所以也不适用 MVCC。
3) READ COMMITTED(提交读)
每次读取数据时都生成一个快照，更新旧的快照，保证能读取到其他事务已经提交的内容。
4) REPEATABLE READ(可重复读)
只在第一次读取数据时生成一个快照，以后不会再更新，后续所有的读操作都是复用这个快照，可以保证每次读操作的一致性。
由此可见，虽然 REPEATABLE READ(可重复读)比 READ COMMITTED(提交读)隔离级别高，但是开销反而相对少，因为不用频繁更新快照。
2. 两种读取数据记录的方式
1) 当前读
读取当前数据的最新版本，而且读取到这个数据之后会对这个数据加锁，防止别的事务更改。在进行写操作时就需要进行“当前读”，读取数据记录的最新版本。
2) 快照读
其实就是读取 MVCC 中的快照，可以读取数据的所有版本信息，包括旧版本的信息。也就是说，“快照读”读到的不一定是数据的最新版本，有可能是之前的历史版本。
在 READ COMMITTED(提交读)隔离级别下，“快照读”和“当前读”结果一样，都是读取已提交的最新版本数据。
在 REPEATABLE READ(可重复读)隔离级别下，“当前读”是其他事务已经提交的最新版本数据，“快照读”是当前事务之前读到的版本，创建快照的时机决定了读到的版本。
在 MySQL 中，MVCC 是由记录中的三个隐式列、undo 日志和快照等来实现的。
02、锁机制
MySQL 支持不同的存储引擎，不同存储引擎的锁定机制也是不同的。例如&
妖狐艹你老母
￡神魔★判官ぃ
╰+哭是因爲堅強的太久メ
灰太狼
还没有评论，来说两句吧...