MySQL——锁机制

 

乐观锁和悲观锁：

乐观锁会“乐观地”假定大概率不会发生并发更新冲突，访问、处理数据过程中不加锁，只在更新数据时再根据版本号或时间戳判断是否有冲突，有则处理，无则提交事务；

悲观锁会“悲观地”假定大概率会发生并发更新冲突，访问、处理数据前就加排他锁，在整个数据处理过程中锁定数据，事务提交或回滚后才释放锁；

表锁（MyISAM，InnoDB）和行锁（InnoDB）

表锁

表共享读锁(table read lock)和表独占写锁（table write lock）

行锁

行共享读锁和行独占写锁

意向锁和间隙锁

意向锁

为了解决行锁和表锁的冲突

事务A锁住了表中的一行，让这一行只能读，不能写。之后，事务B申请整个表的写锁。如果事务B申请成功，那么理论上它就能修改表中的任意一行，这与A持有的行锁是冲突的。在意向锁存在的情况下，事务A必须先申请表的意向共享锁，成功后再申请一行的行锁。

间隙锁

为了防止幻读

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁 （Next-Key锁）。 
举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,…,100,101，下面的SQL：

Select * from  emp where empid > 100 for update;

是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
 

事务隔离实现

多版本并发控制和基于锁的并发控制

MVCC（Multiversion Concurrency Control,多版本并发控制）

最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。 

InnoDB存储引擎在数据库每行数据的后面添加了三个字段分别为事务ID(DB_TRX_ID)，回滚指针(DB_ROLL_PTR)，DB_ROW_ID

当前读：即加锁读，读取记录的最新版本，会加锁保证其他并发事务不能修改当前记录，直至获取锁的事务释放锁；

快照读：即不加锁读，读取记录的快照版本而非最新版本，通过MVCC实现；