mysql并发控制_smyql并发控制语句

Inndb为何并发如此高？

并发控制，为啥要进行并发控制？

并发的任务对同一个临界资源进行操作，如果不采取措施，可能导致不一致，所以必须进行并发控制。

如何进行并发控制？

锁：普通锁、共享锁、排他锁

如何使用普通锁保证一致性？

1. 操作数据前，锁住，实施互斥，不允许其他的并发任务操作；

2. 操作完成后，释放锁，让其他任务执行，来保证一致性；

普通锁存在什么问题？

简单的锁住太过粗暴，连读任务也无法并行，任务执行过程本质上都是串行的。

于是出现了共享锁与排它锁

1. 共享锁(share locks s锁) 读取数据时加S锁，共享锁之间不互斥， 读读可以并发。

2. 排它锁(exclusive locks x锁) 修改数据时加X锁，排它锁与任何锁互斥，写读，写写不可以并行。

可以看到，一旦写数据的任务没有完成，数据是不能被其他任务读取的，这对并发度有较大的影响，对应到数据库，可以理解为，写事物没有提交，读相关数据的查询也会被阻塞。

有没有提高性能的方法？

即使写任务没有完成，其他读任务也可能并发，这就引出了数据多版本的概念（mvcc）

数据多版本是一种能够进一步提高并发的方法，核心原理：

1. 写任务发生时，将数据克隆一份，以版本号区分；

2. 写任务操作新克隆的数据，直至提交；

3. 并发读任务可以继续读取旧版本的数据，不至于阻塞；

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，做到非阻塞并发读。

可以看到，数据多版本，通过“读取旧版本数据”能够极大提高任务的并发度。

提高并发的演进思路，就在如此：

普通锁，本质是串行执行；

读写锁，可以实现读读并发；

数据多版本，可以实现读写并发；

mvcc实现原理

当前读和快照读

先普及一下什么是当前读和快照读。

当前读： 读取数据的最新版本，并对数据进行加锁。

例如：insert、update、delete、select for update、 select lock in share mode。

快照读（Snapshot Read），这种一致性不加锁的读（Consistent Nonlocking Read），就是InnoDB并发如此之高的核心原因之一。

这里的一致性是指，事务读取到的数据，要么是事务开始前就已经存在的数据（当然，是其他已提交事务产生的），要么是事务自身插入或者修改的数据。

除非显示加锁，普通的select语句都是快照读，例如：

select * from t where id>2;

MVCC是基于Undo Log、隐藏字段、Read View（读视图）实现的。

隐藏字段

先说一下MySQL的隐藏字段，当我们创建一张表时，InnoDB引擎会增加2个隐藏字段。

DB_TRX_ID（最近一次提交事务的ID）：修改表数据时，都会提交事务，每个事务都有一个唯一的ID，这个字段就记录了最近一次提交事务的ID。

DB_ROLL_PTR（上个版本的地址）：修改表数据时，旧版本的数据都会被记录到Undo Log日志中，每个版本的数据都有一个版本地址，这个字段记录的就是上个版本的地址。

redo, undo, 回滚段

为什么要有redo日志？

数据库事务提交后，必须将更新后的数据刷到磁盘上，以保证ACID特性。磁盘随机写性能较低，如果每次都刷盘，会极大影响数据库的吞吐量。

优化方式是，将修改行为先写到redo日志里（此时变成了顺序写），再定期将数据刷到磁盘上，这样能极大提高性能。

假如某一时刻，数据库崩溃，还没来得及刷盘的数据，在数据库重启后，会重做redo日志里的内容，以保证已提交事务对数据产生的影响都刷到磁盘上。

一句话，redo日志用于保障，已提交事务的ACID特性。

为什么要有undo日志？

数据库事务未提交时，会将事务修改数据的镜像（即修改前的旧版本）存放到undo日志里，当事务回滚时，或者数据库奔溃时，可以利用undo日志，即旧版本数据，撤销未提交事务对数据库产生的影响。

画外音：更细节的，

对于insert操作，undo日志记录新数据的PK(ROW_ID)，回滚时直接删除；

对于delete/update操作，undo日志记录旧数据row，回滚时直接恢复；

他们分别存放在不同的buffer里。

一句话，undo日志用于保障，未提交事务不会对数据库的ACID特性产生影响。

什么是回滚段？

存储undo日志的地方，是回滚段。