MySQL隔离机制

1. 脏写、脏读、不可重复读、幻读等问题

1）脏写

2）脏读

无论是脏写还是脏读，都是一个事务去更新或查询了另一个事务未提交的数据，如果另一个事务回滚，

就出现了脏写、脏读的情况

3）不可重复读

不可重复读不是什么大问题，具体取决于是否允许不可重复读，如果业务要求事务期间每次读取的

数据都是一致的，这就是问题，需要解决

4）幻读

2. MySQL隔离机制

1）read uncommitted

不允许脏写(不允许两个未提交的事务同时更新一条数据)，但是会出现脏读、不可重复读、幻读问题

2）read committed

不会出现脏写和脏读(查询不到别的事务未提交的数据)，但是会出现不可重复读、幻读

3）repeatable read

不会出现脏写、脏读、不可重复读问题(事务一旦开启，别的事务提交后的值也不会读到)，但是会出现幻读，

这里是mysql比较牛的地方，RR级别下可以解决幻读的问题，要借助于下面所讲的MVCC

4）serializable  

串行化执行，根本就不是并发，所以上述问题都不会出现

3. MVCC

讲MVCC之前，我们有必要聊下undo log版本链。

简单来说，我们每条数据都有两个隐藏的字段trx_id和roll_pointer，trx_id是最近一次更新数据的事务id， roll_pointer指向了你更新这个事务之前生成的undo log

再来看看基于undo log链的ReadView机制

简单说就是执行一个事务的时候，就会生成一个ReadView，里面有4个关键东西

1）m_ids --此时有哪些事务未提交

2）min_trx_id --m_ids里最小的值

3）max_trx_id --表示下一个事务生成时分配给它的id

4）creator_trx_id --当前事务id

 

4. 锁

1）独占锁(X锁)

脏写是绝对不允许的，是靠锁来实现的，让多个事务更新同一行数据串行化，避免同时更新

事务A要更新数据，一看该数据没有人锁定，立马创建一个锁，包含了自己的trx_id和等待状态，然后锁和数据

关联起来；此时事务B也想要更新数据，发现数据已经被加锁了，然后B也生成一个锁，但此时B是等待状态的

 

接着事务A更新完数据提交，会把锁释放掉。一旦锁释放，就会去找还有没有别的事务加锁了，找到B的锁把等

待状态改为false,然后唤醒事务B继续执行，此时事务B就获取到数据了

如果此时别的事务来读取这条数据会加锁嘛？不会，基于MVCC，避免了频繁加锁

2）共享锁(S锁)

select * from table lock in share mode会给当前数据加共享锁

 

此时明白了，独占锁和独占锁是互斥的，别的事务不可以更新操作；如果是查询，默认走MVCC不加锁，如果手

动加共享锁，也是互斥的；最后共享锁和共享锁是不互斥的

3）行锁(上述两种锁讲的就是行锁)

4）表锁(一般不会这样操作)

lock table *** read --表级共享锁

lock table *** write --表级独占锁

查询、更新行数据的时候会在表上加意向锁；分为意向共享锁和意向独占锁