数据库锁和数据库隔离级别

原文链接：http://qiangmzsx.blog.51cto.com/2052549/1402125

最近突然发现忘了数据库锁和数据库隔离级别，时常弄混它们之间的关系。为此特此写下此博客，以方便自己复习，同时也可以帮助博友。

数据库锁

   数据库锁就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。
数据库锁是实现并发控制的重要技术，但是“锁”会带来系统额外的开销。所以需要注意选择封锁粒度时必须同时考虑开销和并发度两个因素，进行权衡，以求得最优的效果。
   锁的类型主要有两种类型排它锁（也叫独占锁）和共享锁，当然还有很多教程增加了一种--更新锁。
共享（S)锁：多个事务可封锁一个共享页；任何事务都不能修改该页； 通常是该页被读取完毕，S锁立即被释放。在执行select语句的时候需要给操作对象（表或者一些记录）加上共享锁，但加锁之前需要检查是否有排他锁，如果没有，则可以加共享锁（一个对象上可以加n个共享锁），否则不行。共享锁通常在执行完select语句之后被释放，当然也有可能是在事务结束（包括正常结束和异常结束）的时候被释放，主要取决与数据库所设置的事务隔离级别。 
排它（X)锁：仅允许一个事务封锁此页；其他任何事务必须等到X锁被释放才能对该页进行访问；X锁一直到事务结束才能被释放。执行insert、update、delete语句的时候需要给操作的对象加排他锁（我感觉在执行insert的时候应该是在表级加排他锁），在加排他锁之前必须确认该对象上没有其他任何锁，一旦加上排他锁之后，就不能再给这个对象加其他任何锁。排他锁的释放通常是在事务结束的时候（当然也有例外，就是在数据库事务隔离级别被设置成Read Uncommitted（读未提交数据）的时候，这种情况下排他锁会在执行完更新操作之后就释放，而不是在事务结束的时候）。 
更新（U)锁：用来预定要对此页施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；当被读取的页将要被更新时，则升级为X锁；U锁一直到事务结束时才能被释放。数据库是支持在一个事务中进行自动锁升级的，例如，在某个事务中先执行select语句，后执行update语句，这两条语句操作了同一个对象，并且假定共享锁是在事务结束的时候被释放的。如果数据库不支持自动锁升级，那么当update语句请求排他锁的时候将不能成功。因为之前select语句的共享锁没有被释放，那么事务就进入了无限等待，即死锁。有了自动锁升级，在执行update语句的时候就可以将之前加的共享锁升级为排他锁，但有个前提，就是这个共享锁必须是本事务自己加的，而且在操作对象上没有在加其他任何锁，否则共享锁是不能被升级为排他锁的，必须等待其他锁的释放。
　　因为通常在执行更新操作的时候要先查询，也就是我们通常会在update语句和delete语句中加where子句。那么，有的数据库系统可能会在执行查询的时候先给操作对象加共享锁，然后在更新的时候加排他锁，但这么做会有问题，也就是如果两个事务同时要更新一个对象，都先给这个对象加了共享锁，当要更新的时候，都请求升级锁，但由于这个对象上存在对方事务加的共享锁。。所以无法升级。这样两个事务就在等待对方释放共享锁，进入死锁状态。更新锁就是为了解决这个问题，即在执行查询操作的时候加的不是共享锁而是更新锁（一个对象上只能有一个更新锁和n个共享锁），当要更新的时候，再将更新锁升级为排他锁，升级前提是这个对象上只有本事务加的更新锁，没有其他任何锁了。其实，，我想，如果在执行查询的时候就给事务加排他锁不也能解决死锁问题吗，但这样似乎会减弱系统的并发性能。