1. 锁类型
共享锁(S锁):假设事务T1对数据A加上共享锁，那么事务T2可以读数据A，不能修改数据A。
排他锁(X锁):假设事务T1对数据A加上共享锁，那么事务T2不能读数据A，不能修改数据A。
我们通过update、delete等语句加上的锁都是行级别的锁。只有LOCK TABLE … READ和LOCK TABLE … WRITE才能申请表级别的锁。
意向共享锁(IS锁):一个事务在获取（任何一行/或者全表）S锁之前，一定会先在所在的表上加IS锁。
意向排他锁(IX锁):一个事务在获取（任何一行/或者全表）X锁之前，一定会先在所在的表上加IX锁。
意向锁存在的目的?
假设事务T1，用X锁来锁住了表上的几条记录，那么此时表上存在IX锁，即意向排他锁。那么此时事务T2要进行LOCK TABLE … WRITE的表级别锁的请求，可以直接根据意向锁是否存在而判断是否有锁冲突。
Record Locks：简单翻译为行锁吧。注意了，该锁是对索引记录进行加锁！锁是在加索引上而不是行上的。注意了，innodb一定存在聚簇索引，因此行锁最终都会落到聚簇索引上！
Gap Locks：简单翻译为间隙锁，是对索引的间隙加锁，其目的只有一个，防止其他事物插入数据。在Read Committed隔离级别下，不会使用间隙锁。这里我对官网补充一下，隔离级别比Read Committed低的情况下，也不会使用间隙锁，如隔离级别为Read Uncommited时，也不存在间隙锁。当隔离级别为Repeatable Read和Serializable时，就会存在间隙锁。
Next-Key Locks：这个理解为Record Lock+索引前面的Gap Lock。记住了，锁住的是索引前面的间隙！比如一个索引包含值，10，11，13和20。那么，间隙锁的范围如下，我们平时说的表锁其实就是使用Next-Key Locks实现的
官方文档：InnoDB Locking
2. MVCC
InnoDB使用MVCC机制来提升RR隔离级别的并发性。MVCC (Multi-Version Concurrency Control)多版本并发控制协议，将读操作分成两类：快照读 与当前读 。读取的是记录的最新版本，会对返回的记录加上锁，确保其他事务不能并发修改。
快照读：简单的查询操作，属于快照读，不加锁。如：
1 select * from table where ?;
当前读：特殊的读操作及插入/更新/删除操作，属于当前读，需要加锁。以下都是当前读：
1 select * from table where ? lock in share mode;
2 select * from table where ? for update;
3 insert into table values (…);
4 update table set ? where ?;
5 delete from table where ?;
快照读是通过undo log来实现多个版本的控制。如下图，每个数据行：row_id 为行id，trx_id表示最近修改的事务id，db_roll_ptr为指向undo segment中undo log的指针。快照读时，比较当前事务id与trx_id的关系，如果trx_id 小于事务id，则该条数据对当前事务可见，反之不可见，不可见时再通过db_roll_ptr查找历史版本记录，取出可见的最近的历史记录。undo log 的链路不会很深，后台purge线程定期清除无用的历史版本（在没有活动事务依赖时，undo log即可被删除）。
3 加锁分析：总结于何登成的《 InnoDB加锁处理分析》
当前读都会加锁，怎么加？则要看具体情景——隔离级别及索引情况。
在InnoDB的RR隔离级别下，对于同一条SQL语句：
DELETE FROM T1 WHERE ID=10;
当ID列为主键时：锁主键索引上id=10的记录。
当ID列为唯一索引：先锁唯一索引上的id=10的行，再锁主键索引上name=d的行。
当ID列为二级索引：在二级索引上，会给id=10的所有行加X锁，而且会给被锁行的前后范围加GAP锁；主键索引上，给相应记录加X锁。
当ID列未加索引：此种情况后果很严重！主键索引所有行都被加X锁，所有间隙被加GAP锁！全表的数据都被锁的，没有并发可言，因此一定要检查当前读的where条件语句是否走索引。
GAP锁的意义：当前事务占住间隙范围，避免其它事务往这个范围插入数据，引起幻读，只发生在RR隔离级别。如果id列是唯一索引（或主键索引 ），且当前读条件语句中的id不存在时，InnoDB也会给范围加GAP锁。
