mysql锁与事务（MVCC、BufferPool）

锁

概述：锁分为乐观锁和悲观锁，cas锁是乐观锁，mysql中的读锁和写锁都是悲观锁。
cas锁：修改数据时判断数据版本号是否是修改之前的数据，如果数据已经被修改则放弃本次修改或者取出最新数据重新进行计算修改直到修改成功。
读锁（共享锁）：给数据加读锁，所有事务线程都可以读取数据，但除了当前线程之外其他线程对数据的新增和修改会被阻塞。
写锁（排它锁）：除当前线程之外，其他线程对锁定数据的所有操作（增删改查）均会被阻塞。

表锁：锁定整张表，语法如下

//读锁
lock table user read;
//写锁
lock table user write;

PS：锁一般是加载索引上，而不是数据上

行锁与事务隔离

事务的ACID属性
原子性（Atomicity）：一个事务应当看做一个最小的整体，事务内的要做要么都成功，要么都失败。
一致性（Consistent）：事务前后的数据应该保持一致的变更，要么都变更，要么都回滚
隔离性（Isolation）：事务和事务之间应该互相隔离，一个事务不应该受到其他事务的操作影响。
持久性（Durable）：事务的执行结果应该是永久的，就算服务器宕机了也会保存下来。
mysql事务隔离分为四个等级

隔离级别	脏读	不可重复度	幻读
读未提交	可能	可能	可能
读已提交	不可能	可能	可能
可重复读	不可能	不可能	可能
可串行化	不可能	不可能	不可能

脏读：一个事务在执行时读取到了另一个事务未提交的数据修改，违背了事务的隔离性
不可重复读：一个事务在多次读取同一条数据时该数据的状态不同，例如第一次是1，第二次是2，这种会造成逻辑混乱的情况称为不可重复读
幻读：一个事务可以操作本不应该存在（查询不到）的数据，该情况称之为幻读，例如事务A在执行过程中，事务B提交了修改，那么即使事务A看不到事务B的修改，也可以修改事务B变化后的数据，该情况称之为幻读

读未提交：不做隔离，任何操作都是全局操作
读已提交：事务只有在commit之后才会产生全局影响，没有commit之前所有的数据不会产生真实的变化。
可重复读：事务之间互相隔离，一个事务在生成事务ID后所有其他事务对数据的修改都不再会体现在该事务内的查询之中
可串行化：所有的操作由并行改为单线程执行。

mvcc

mysql事务中的读已提交和可重复度两种隔离机制都用到了mvcc机制。

mvcc机制简单来说有以下几点。

1：事务在began的时候并没有生成事务ID，在执行第一条查询sql的时候才会生成事务ID。
2：事务ID生成时会同时生成一个read view，read view里保存所有当前已开始但未提交的事务ID以及一个已提交的数字最大的事务ID。
3：在查询数据时从undo版本链中寻找数据的历史版本，排除掉所有read里存储的当前未提交的事务对数据的修改和大于查询时提取的最大事务ID的事务对数据的修改之后返回数据（简单来说就是排除掉在生成read view时所有未提交/未创建的事务对数据的修改结果。）

读已提交和可重复读中mvcc机制实现的异同
读已提交在执行每条查询sql时会重新生成read view，所以已提交的事务对数据产生的影响都能查出来，两次读取结果可能不一样。
可重复度只有在执行第一条查询sql时候生成一次read view，所以一个事务中无论读取多少次，结果都是一样的。

PS：数据隔离只是隔离了查询结果，最终修改时还是会按照修改时数据库中的真实数据进行修改，所以在修改时依旧要考虑数据可能已经被其他的事务修改了的可能性

mysql默认的隔离级别是可重复度，可重复读在某些情况下可以使用间隙锁解决幻读的问题。

间隙锁(Gap Lock)
假如数据库中的数据有过删除，ID 为1,2,4,10,20
那么数据库中的间隙就有（2,4）（4，10）（10，20）（20，正无限）四组
此时如果对这四组间隙之间的ID进行操作，例如：

update user set name =‘s1’ where id >10 and id <25;

那么，由于条件的范围跨越了（10，20）（20，正无限）两组间隙，那么id位于这两组间隙之中的所有数据在该update进行commit前都会阻塞。
例如

update user set name =‘s2’ where id =11；

就会被阻塞，无法执行

临键锁(Next-key Locks)

临键锁的概念建立在间隙锁上，如果修改语句改成下面这样：

update user set name =‘s1’ where id >10 and id <19;

条件只跨越了（10，20）一组间隙，那么对ID是20的数据也无法修改，但对ID是10的可以修改，这就是临键锁，隙范围之中，位于最后的那个值的数据也将被锁定。

无索引行锁会升级为表锁
InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁

bufferpool缓存

首先明确一个概念，mysql的数据磁盘读写是随机读写，效率不高，并且在进行磁盘读取时中间有一层缓存，并不一定是直接读取的磁盘，详细逻辑如下：

ps：图上忘记画了，数据修改的第三步是修改缓存中的数据

直接对磁盘上的数据文件进行随机读取效率是很慢的，上面的执行逻辑虽然看似复杂，但避免了每次对磁盘数据文件进行随机读取，对缓存的读取和文件IO比起来效率要快上许多倍，同时利用多个日志文件保证了数据的一致性，而且对日志文件的读写是顺序读写，效率也会比随机读取数据文件快很多，就算宕机也可以保证数据的一致性。
基于这个架构mysql才能同时支撑大量的并发产生。