看了两本书，一本是《高性能MySQL》,一本是《MySQL技术内幕——InnoDB存储引擎》，感觉要不写点什么，就白看了，本篇主要以MySQL的InnoDB为例，聊聊lock的相关东西
一、什么是lock
锁是数据库系统区别于文件系统的一个关键性特征，锁机制用于管理对共享资源的并发访问，而lock主要是针对数据库中的对象，如表、页、行，并且一般lock的对象仅在事务commit或rollback后进行释放。
对于InnoDB可以通过如下命令来观察锁的情况
select * from information_schema.INNODB_TRX; #查看事务情况
select * from information_schema.INNODB_LOCKS; #查看锁情况
select * from information_schema.INNODB_LOCK_WAITS; #查看锁等待情况
二、InnoDB中lock的类型
InnoDB存储引擎实现了以下两种标准的行级锁
共享锁（S Lock）：也叫读锁，故名思议在读取的时候给数据对象加锁
排他锁（X Lock）：也叫写锁，为了避免并发写出现不可预知的后果，在修改数据对象的时候给数据加锁
一个记录（row），可以同时拥有多个S锁，但是同时只能拥有一个X锁，X锁会阻塞其他线程对记录的操作，需要注意的是S锁和X锁都是行锁，兼容是指对同一记录（row）锁的兼容情况，下面有一个锁的兼容表
三、一致性非锁定读
什么是一致性非锁定读和一致性锁定读，他们各有什么优缺点，如何使用他们（显示或者隐身使用），他们跟其他那些东西还有什么样的关联，对其影响如何
一致性非锁定读是指的是InnoDB存储引擎通过多版本控制（MVCC）的技术来读取行数据，就算被读取行正在执行更新和删除操作也不会被阻塞，相反地，InnoDB存储引擎会去读取行的一个快照数据。
之所以叫做一致性非锁定读，是因为不需要等待访问行上的X锁的释放。非锁定读极大的提高了数据库的并发性能，在InnoDB存储引擎中默认的就是以这种方式读取，需要注意的是，不同的事务隔离级别下是否采用一致性非锁定读和快照数据的定义也都各不相同。
在MySQL（其他的实现方式不一样，比如PostgreSQL）的InnoDB中，仅在 READ COMMITTED 和 REPEATABLE READ下使用MVCC，所以也仅在这两张隔离级别下才会使用一致性非锁定读。对于快照数据版本，在 READ COMMITTED 下总是读取被锁定行的最新的一份快照；而在 REPEATABLE READ 下总是读取事务开始时的行数据版本（不会出现幻读）
四、一致性锁定读
有了上面一致性非锁定读的解释，相信一致性锁定读就更好理解，简单来说就是在读取行的时候不在允许其他用户对行进行修改和删除，也叫做不允许加排它锁
在某些情况下，用户需要显示地对数据库读取操作进行加锁以保证数据逻辑一致性，这时候就需要用到手动加锁的情况，InnoDB提供了两种读取时手动加锁的方法如下
SELECT ... FOR UPDATE
SELECT ... LOCK IN SHARE MODE
两个语句实现上是有一定区别的， FOR UPDATE 是对读取的行加一个X锁，而 LOCK IN SHARE MODE 对读取行加一个S锁。在使用的时候需要将语句放在事务中执行，一旦离开事务锁就会自动释放，当然为了防止死锁，时间长了数据库也会自动释放锁
这里需要注意的是，在使用了MVCC的事务隔离级别下即便是加了X锁，其他用户也是可以读取数据的，只是读取的是对应快照数据。在 SERIALIZABLE 隔离级别下就可看到两个语句的不同，FOR UPDATE 会阻塞其他用户对行的读取，而 LOCK IN SHARE MODE 却不会。
五、锁的算法
InnoDB存储引擎有三种行锁算法：
Record Lock：单个行记录上的锁
Gap Lock：间隙锁，锁定一个范围，但不包含记录本身
Next-Key Lock：Gap Lock + Record Lock，锁定一个范围，并且锁定记录本身
InnoDB对于行的查询都使用了Next-Key Lock的算法，Record Lock比较好理解，Gap Lock要复杂点，因为InnoDB在索引、主键、事务隔离级别都会对其有一定的影响
1、条件查询单列，非索引
此时当我们通过for update显示锁定某一行的时候，其实根据Next-Key Lock算法会采用间隙锁的方式，这时增加、删除、修改其他行都会被阻塞，其锁定的是（-∞，+∞）
2、条件查询单列，非唯一索引
同上，存储引擎还是会使用Next-Key Lock的方式，不过这时锁定的不在是（-∞，+∞），而是锁定的我们指定行的前后区间，即（pre,x]和（x,next）。所以我们在操作pre和之前，以及next和之后的行都不会阻塞
3、条件查询单列，唯一索引
InnoDB对于这种情况会有特殊的优化，由于是唯一索引，所以没必要在指定锁定一行时使用间隙锁，这时候会降级使用Record Lock，仅锁住索引记录本身，需要注意主键也是唯一索引
4、条件查询多列，多索引
这种情况其实就是取的一个并集，每个列对应索引锁定的区间合起来的并集
5、联合索引的问题
这个在书中有特别提到，当一个唯一索引是联合索引时，但是查询条件仅是其中部分列的话，还是会使用Next-Key Lock
6、显示关闭使用Gap Lock
可以通过修改事务隔离级别READ COMMITTED显示关闭
通设置参数innodb_locks_unsafe_for_binlog=1
7、Next-Key Locking 与幻象问题
Mysql中默认事务隔离级别下，即REPEATABLE READ下，InnoDB存储引擎采用Next-Key Locking机制就可以保证幻象问题，而不需要使用SERIALIZABLE隔离级别
五、阻塞、死锁
阻塞
因为不同锁之间的兼容性关系，在有些时刻一个事务中的锁需要等待另外一个事务中的锁释放它所占用的资源。这就是阻塞，阻塞并不是一件坏事情，其实是为了确保事务可以并发且正常的运行，在InnoDB存储引擎中，有一些变量来控制等待的相关操作
innodb_lock_wait_timeout：控制等待的时间（默认50秒）
innodb_rollback_on_timeout：设定是否在等待超时时对进行中的事务进行回滚操作（默认是OFF，不回滚）
死锁
死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象
如何解决死锁？
1、超时回滚
当事务相互等待的时候，一个事务等待时间超过设置的阀值，就将其回滚，而另外的事务就能继续的进行
缺点也是显而易见的，如果超时的事务所占权重比较大，如事务操作更新了很多行，占用了较多的undo log，这时显得就不合适了，因为回滚的这个事务的时间相对另外的事务所占时间可能会很多
2、wait-for garph（等待图）
这是一种主动的死锁检查方式，InnoDB引擎也采用这种方式，在每个事务请求锁并发生等待时都会判断是否存在回路，若存在，通常来说InnoDB选择回滚undo量最小的事务，wait-for garph要求数据库保存两种信息，1、锁的信息链表；2、事务等待链表。通过这样的链表可以构造出一张图，而图中存在回路就代表存在死锁。
影响死锁概率的因素
1、系统中事务的数量，越多发生死锁概率越大
2、每个事务操作的数量，操作数量越多，概率越大
3、操作数据的集合，越小发生死锁概率越大
六、基于锁的并发思考
扩展阅读
关于MySQL/InnoDB的加锁规则扩展阅读，作者分析的很透彻
http://hedengcheng.com/?p=771