数据库锁机制

这段时间由于开发项目，重新学习了数据库的并发控制和锁机制。数据库就是通过锁机制来解决并发问题的。。主要就是两种锁，共享锁和排他锁（也叫独占锁）。在执行select语句的时候需要给操作对象（表或者一些记录）加上共享锁，但加锁之前需要检查是否有排他锁，如果没有，则可以加共享锁（一个对象上可以加n个共享锁），否则不行。共享锁通常在执行完select语句之后被释放，当然也有可能是在事务结束（包括正常结束和异常结束）的时候被释放，主要取决与数据库所设置的事务隔离级别。

　　执行insert、update、delete语句的时候需要给操作的对象加排他锁（我感觉在执行insert的时候应该是在表级加排他锁），在加排他锁之前必须确认该对象上没有其他任何锁，一旦加上排他锁之后，就不能再给这个对象加其他任何锁。排他锁的释放通常是在事务结束的时候（当然也有例外，就是在数据库事务隔离级别被设置成Read Uncommitted（读未提交数据）的时候，这种情况下排他锁会在执行完更新操作之后就释放，而不是在事务结束的时候）。
　　数据库是支持在一个事务中进行自动锁升级的，例如，在某个事务中先执行select语句，后执行update语句，这两条语句操作了同一个对象，并且假定共享锁是在事务结束的时候被释放的。如果数据库不支持自动锁升级，那么当update语句请求排他锁的时候将不能成功。因为之前select语句的共享锁没有被释放，那么事务就进入了无限等待，即死锁。有了自动锁升级，在执行update语句的时候就可以将之前加的共享锁升级为排他锁，但有个前提，就是这个共享锁必须是本事务自己加的，而且在操作对象上没有在加其他任何锁，否则共享锁是不能被升级为排他锁的，必须等待其他锁的释放。
　　在看《精通Hibernate》的时候，里面还提到了更新锁。因为通常在执行更新操作的时候要先查询，也就是我们通常会在update语句和delete语句中加where子句。那么，有的数据库系统可能会在执行查询的时候先给操作对象加共享锁，然后在更新的时候加排他锁，但这么做会有问题，也就是如果两个事务同时要更新一个对象，都先给这个对象加了共享锁，当要更新的时候，都请求升级锁，但由于这个对象上存在对方事务加的共享锁。。所以无法升级。这样两个事务就在等待对方释放共享锁，进入死锁状态。更新锁就是为了解决这个问题，即在执行查询操作的时候加的不是共享锁而是更新锁（一个对象上只能有一个更新锁和n个共享锁），当要更新的时候，再将更新锁升级为排他锁，升级前提是这个对象上只有本事务加的更新锁，没有其他任何锁了。其实，，我想，如果在执行查询的时候就给事务加排他锁不也能解决死锁问题吗，但这样似乎会减弱系统的并发性能。
　　现在说说数据库的事务隔离级别。
　　在《精通Hibernate》中提到了4种数据库事务隔离级别：
Read Uncommitted：读未提交数据（这个通常很少用）
　　使用这种隔离级别并不是说在读取或者更新数据的时候不加锁。。其实还是加锁的，只是在执行完操作之后马上释放锁。而不是等到事务结束之后再释放。对于共享锁，排他锁都是这样。
Read Committed：读已提交数据（这个很常用，也常是数据库默认的设置）
　　这种隔离级别共享锁在读取数据之后马上释放。。而排他锁则是在事务结束的时候再释放。
Repeatable Read：可重复读
　　这种隔离级别共享锁和排他锁都是在事务结束的时候再释放的。因此叫“可重复读”，即一个事务所读取的数据是不会被别的事务更新的。。。在事务执行过程中任何时候都可以读取刚才读过的数据。读过的数据是不会被改变的，直到事务结束。
Serializable：串行化
　　共享锁和排他锁也是在事务结束的时候被释放，和Repeatable Read不同的是，通常，Repeatable Read。。在读取数据的时候。。都是对一条条记录加共享锁的。而Serializable的共享锁则是对整个表加的，这样不但读取的数据不会被别的事务修改。。。在同一个表中的其他未被读取的数据也不会被修改，，甚至不用担心读到新加入这个表中的数据（根本无法往表中加数据），所以这种隔离级别是不会出现虚读的。

以下一篇来自点击打开链接

锁是网络数据库中的一个非常重要的概念，它主要用于多用户环境下保证数据库完整性和一致性。各种大型数 据库所采用的锁的基本理论是一致的，但在具体实现上各有差别。目前，大多数数据库管理系统都或多或少具有自我调节、自我管理的功能，因此很多用户实际上不 清楚锁的理论和所用数据库中锁的具体实现。 

Microsoft SQL Server（以下简称SQL Server）作为一种中小型数据库管理系统，已经得到了广泛的应用，该系统更强调由系统来管理锁。在用户有SQL请求时，系统分析请求，自动在满足锁定 条件和系统性能之间为数据库加上适当的锁，同时系统在运行期间常常自动进行优化处理，实行动态加锁。对于一般的用户而言，通过系统的自动锁定管理机制基本 可以满足使用要求，但如果对数据安全、数据库完整性和一致性有特殊要求，就必须自己控制数据库的锁定和解锁，这就需要了解SQL Server的锁机制，掌握数据库锁定方法。 

锁的多粒度性以及锁升级 

数据库中的锁是指一种软件机制，用来指示某个用 户（也即进程会话，下同）已经占用了某种资源，从而防止其他用户做出影响本用户的数据修改或导致数据库数据的非完整性和非一致性。这儿所谓资源，主要指用 户可以操作的数据行、索引以及数据表等。根据资源的不同，锁有多粒度（multigranular）的概念，也就是指可以锁定的资源的层次。SQL Server中能够锁定的资源粒度包括：数据库、表、区域、页面、键值（指带有索引的行数据）、行标识符（RID，即表中的单行数据）。 

采 用多粒度锁的重要用途是用来支持并发操作和保证数据的完整性。SQL Server根据用户的请求，做出分析后自动给数据库加上合适的锁。假设某用户只操作一个表中的部分行数据，系统可能会只添加几个行锁（RID）或页面 锁，这样可以尽可能多地支持多用户的并发操作。但是，如果用户事务中频繁对某个表中的多条记录操作，将导致对该表的许多记录行都加上了行级锁，数据库系统 中锁的数目会急剧增加，这样就加重了系统负荷，影响系统性能。因此，在数据库系统中，一般都支持锁升级(lock escalation)。所谓锁升级是指调整锁的粒度，将多个低粒度的锁替换成少数的更高粒度的锁，以此来降低系统负荷。在SQL Server中当一个事务中的锁较多，达到锁升级门限时，系统自动将行级锁和页面锁升级为表级锁。特别值得注意的是，在SQL Server中，锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置。 

锁的模式和兼容性 

在数据库中加锁时，除了可以对不同的资源加锁，还可以使用不同程度的加锁方式，即锁有多种模式，SQL Server中锁模式包括： 

1．共享锁 

SQL Server中，共享锁用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。默认情况下，数据被读取后，SQL Server立即释放共享锁。例如，执行查询“SELECT * FROM my_table”时，首先锁定第一页，读取之后，释放对第一页的锁定，然后锁定第二页。这样，就允许在读操作过程中，修改未被锁定的第一页。但是，事务 隔离级别连接选项设置和SELECT语句中的锁定设置都可以改变SQL Server的这种默认设置。例如，“ SELECT * FROM my_table HOLDLOCK”就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。 

2．修改锁 

修 改锁在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。因为使用共享锁时，修改数据的操作分为两步，首先获得一 个共享锁，读取数据，然后将共享锁升级为独占锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个事务申请了共享锁，在修改数据的时候，这些 事务都要将共享锁升级为独占锁。这时，这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申请修改锁，在数据修 改的时候再升级为独占锁，就可以避免死锁。修改锁与共享锁是兼容的，也就是说一个资源用共享锁锁定后，允许再用修改锁锁定。 

3．独占锁 

独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。 

4．结构锁 

结构锁分为结构修改锁（Sch-M）和结构稳定锁（Sch-S）。执行表定义语言操作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。 

5．意向锁 

意 向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。例如，表级的共享意向锁说明事务意图将独占锁释放到表中的页或者行。意向锁又可以分为共享意向锁、 独占意向锁和共享式独占意向锁。共享意向锁说明事务意图在共享意向锁所锁定的低层资源上放置共享锁来读取数据。独占意向锁说明事务意图在共享意向锁所锁定 的低层资源上放置独占锁来修改数据。共享式独占锁说明事务允许其他事务使用共享锁来读取顶层资源，并意图在该资源低层上放置独占锁。 

6．批量修改锁 

批量复制数据时使用批量修改锁。可以通过表的TabLock提示或者使用系统存储过程sp_tableoption的“table lock on bulk load”选项设定批量修改锁。 

另外，SQL Server命令语句操作会影响锁定的方式，语句的组合也同样能产生不同的锁定，详情如下表： 

锁冲突及其防止办法 

在数据库系统中，死锁是指多个用户（进程）分别锁定了一个资源，并又试图请求锁定对方已经锁定的资源，这就产生了一个锁定请求环，导致多个用户（进程）都处于等待对方释放所锁定资源的状态。 

在SQL Server中，系统能够自动定期搜索和处理死锁问题。系统在每次搜索中标识所有等待锁定请求的进程会话，如果在下一次搜索中该被标识的进程仍处于等待状态，SQL Server就开始递归死锁搜索。