mysql锁和mvcc

一、锁

 

乐观锁：并不是真的加锁，而是通过业务层面辅助以达到加锁的效果，比如场景的比较版本号。

悲观锁：是真的Mysql锁，比如select for update 或者select in share mode就是悲观锁

共享锁，加了共享锁的事务，其他事务还可以加共享锁，但不能加排他锁。共享锁的使用场景一般是事务执行过程中我需要使用该数据，但是我又不希望其事务修改改数据，这个时候就可以使用共享锁。

排他锁，加了排他锁的事务，其他事务不能加任何的锁。排他锁的使用场景一般是事务执行过程中我需要使用该数据，而且我还要修改该数据，这个时候就可以使用排他锁。

表锁，InnoDB和MyISAM 引擎都支持表锁，加锁快，没有死锁，但并发度低。

行锁，只有InnoDB支持，加锁满，有死锁，但并发度高。InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

记录锁、gap锁、next-key锁其实是行锁在业务中的具体表现，记录锁就是锁住当前记录，gap锁是锁住某个范围，不包含当前记录；next-key锁是锁住某个范围，而且包含当前记录，next-key锁=记录锁+gap锁。

 

二、MVCC（InnoDB,这里特意标明引擎，是因为各引擎实现MVCC是有区别的）

1、基本概念

Mutli-Version Concurreny Control,多版本并发控制，读不加锁，读写不冲突。应用于 Read Commited 和 Repeatable read 两个事务隔离级别，是一种用来解决读-写冲突的无锁并发控制。

MVCC可以为数据库解决以下问题：

1）在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能

2）同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

在Mysql中，因为有了MVCC，所以我们可以形成两个组合：

MVCC + 悲观锁

MVCC解决读写冲突，悲观锁解决写写冲突

MVCC + 乐观锁

MVCC解决读写冲突，乐观锁解决写写冲突

 

2、实现原理

MVCC的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。

 

隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义DB_TRX_ID,DB_ROLL_PTR,默认主键ID

DB_TRX_ID

6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID

DB_ROLL_PTR

7byte，回滚指针，用于配合undo日志，指向这条记录的上一个版本（存储于rollback segment里）

默认主键ID

一般没有设置的时候Mysql的InnoDB会默认生成一个

 

undo日志（undo log主要分为两种）：

insert undo log

代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

update undo log

事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

 

read view

Read View简单的理解成有三个全局属性

trx_list（活跃事务ID列表）

一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID

up_limit_id

记录trx_list列表中事务ID最小的ID

low_limit_id

ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1

 

快照读生成read view的逻辑

首先比较DB_TRX_ID < up_limit_id, 如果小于，则当前事务能看到DB_TRX_ID 所在的记录，如果大于等于进入下一个判断

接下来判断 DB_TRX_ID 大于等于 low_limit_id , 如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断

判断DB_TRX_ID 是否在活跃事务之中，trx_list.contains(DB_TRX_ID)，如果在，则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的；如果不在，则说明，你这个事务在Read View生成之前就已经Commit了，你修改的结果，我当前事务是能看见的.

 

RC,RR级别下快照读的结果的不同

在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见

而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因.