数据库锁简析（转载）

时间  2019-11-12
标签 数据库 转载 栏目 SQL 繁體版
原文   原文链接

1、前言

数据库大并发操做要考虑死锁和锁的性能问题。这里作个简明解释，为下面描述方便，这里用T1表明一个数据库执行请求，T2表明另外一个请求，也能够理解为T1为一个线程，T2 为另外一个线程。T3,T4以此类推。下面以SQL Server为例。html

2、锁的种类

  1. 共享锁(Shared lock)。 
    例1：
----------------------------------------
T1:    select * from table (请想象它须要执行1个小时之久，后面的sql语句请都这么想象）
T2:    update table set column1='hello'

过程：

T1运行 （加共享锁)
T2运行
If T1 还没执行完
    T2等......
else
    锁被释放
    T2执行
endif

T2之因此要等，是由于T2在执行update前，试图对table表加一个排他锁，
而数据库规定同一资源上不能同时共存共享锁和排他锁。因此T2必须等T1
执行完，释放了共享锁，才能加上排他锁，而后才能开始执行update语句。

例2：
----------------------------------------
T1:    select * from table
T2:    select * from table

这里T2不用等待T1执行完，而是能够立刻执行。

分析：
T1运行，则table被加锁，好比叫lockA
T2运行，再对table加一个共享锁，好比叫lockB。

两个锁是能够同时存在于同一资源上的（好比同一个表上）。这被称为共
享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源，但阻
止其它session update

例3：
----------------------------------------
T1:    select * from table
T2:    select * from table
T3:    update table set column1='hello'

此次，T2不用等T1运行完就能运行，T3却要等T1和T2都运行完才能运行。
由于T3必须等T1和T2的共享锁所有释放才能进行加排他锁而后执行update
操做。

例4：（死锁的发生）
----------------------------------------
T1:
begin tran
select * from table (holdlock) (holdlock意思是加共享锁，直到事务结束才释放)
update table set column1='hello'

T2:
begin tran
select * from table(holdlock)
update table set column1='world'

假设T1和T2同时达到select，T1对table加共享锁，T2也对加共享锁，当
T1的select执行完，准备执行update时，根据锁机制，T1的共享锁须要升
级到排他锁才能执行接下来的update.在升级排他锁前，必须等table上的
其它共享锁释放，但由于holdlock这样的共享锁只有等事务结束后才释放，
因此由于T2的共享锁不释放而致使T1等(等T2释放共享锁，本身好升级成排
他锁），同理，也由于T1的共享锁不释放而致使T2等。死锁产生了。

例5：
----------------------------------------
T1:
begin tran
update table set column1='hello' where id=10

T2:
begin tran
update table set column1='world' where id=20

这种语句虽然最为常见，不少人以为它有机会产生死锁，但实际上要看情
况，若是id是主键上面有索引，那么T1会一会儿找到该条记录(id=10的记
录），而后对该条记录加排他锁，T2，一样，一会儿经过索引定位到记录，
而后对id=20的记录加排他锁，这样T1和T2各更新各的，互不影响。T2也不
须要等。

但若是id是普通的一列，没有索引。那么当T1对id=10这一行加排他锁后，
T2为了找到id=20，须要对全表扫描，那么就会预先对表加上共享锁或更新
锁或排他锁(依赖于数据库执行策略和方式，好比第一次执行和第二次执行
数据库执行策略就会不一样）。但由于T1已经为一条记录加了排他锁，致使
T2的全表扫描进行不下去，就致使T2等待。

死锁怎么解决呢？一种办法是，以下：
例6：
----------------------------------------
T1:
begin tran
select * from table(xlock) (xlock意思是直接对表加排他锁)
update table set column1='hello'

T2:
begin tran
select * from table(xlock)
update table set column1='world'

这样，当T1的select 执行时，直接对表加上了排他锁，T2在执行select时，就须要等T1事物彻底执行完才能执行。排除了死锁发生。
但当第三个user过来想执行一个查询语句时，也由于排他锁的存在而不得不等待，第四个、第五个user也会所以而等待。在大并发
状况下，让你们等待效果可想而知，因此，这里引入了更新锁。
  2. 更新锁(Update lock) 
    为解决死锁，引入更新锁。

例7：
----------------------------------------
T1:
begin tran
select * from table(updlock) (加更新锁)
update table set column1='hello'
T2:
begin tran
select * from table(updlock)
update table set column1='world'

更新锁的意思是：“我如今只想读，大家别人也能够读，但我未来可能会作更新操做，我已经获取了从共享锁（用来读）到排他锁
（用来更新）的资格”。一个事务只能有一个更新锁获此资格。

T1执行select，加更新锁。
T2运行，准备加更新锁，但发现已经有一个更新锁在那儿了，只好等。

当后来有user三、user4...须要查询table表中的数据时，并不会由于T1的select在执行就被阻塞，照样能查询，相比起例6，这提升
了效率。

例8:
----------------------------------------
T1:    select * from table(updlock)    (加更新锁）
T2:    select * from table(updlock)    (等待，直到T1释放更新锁，由于同一时间不能在同一资源上有两个更新锁）
T3:    select * from table (加共享锁，但不用等updlock释放，就能够读）

这个例子是说明：共享锁和更新锁能够同时在同一个资源上。这被称为共享锁和更新锁是兼容的。

例9:
----------------------------------------
T1:
begin
select * from table(updlock)      (加更新锁）
update table set column1='hello'  (重点：这里T1作update时，不须要等T2释放什么，而是直接把更新锁升级为排他锁，而后执行update)
T2:
begin
select * from table               (T1加的更新锁不影响T2读取）
update table set column1='world'  (T2的update须要等T1的update作完才能执行)

咱们以这个例子来加深更新锁的理解，

第一种状况：T1先达，T2紧接到达；在这种状况中，T1先对表加更新锁，T2对表加共享锁，假设T2的select先执行完，准备执行update，
发现已有更新锁存在，T2等。T1执行这时才执行完select，准备执行update，更新锁升级为排他锁，而后执行update，执行完成，事务
结束，释放锁，T2才轮到执行update。

第二种状况：T2先达，T1紧接达；在这种状况，T2先对表加共享锁，T1达后，T1对表加更新锁，假设T2 select先结束，准备
update，发现已有更新锁，则等待，后面步骤就跟第一种状况同样了。

这个例子是说明：排他锁与更新锁是不兼容的，它们不能同时加在同一子资源上。
  3. 排他锁（独占锁，Exclusive Locks) 
    这个简单，即其它事务既不能读，又不能改排他锁锁定的资源。
例10
T1:    update table set column1='hello' where id<1000
T2:    update table set column1='world' where id>1000

假设T1先达，T2随后至，这个过程当中T1会对id<1000的记录施加排他锁.但不会阻塞T2的update。

例11 (假设id都是自增加且连续的）
T1:    update table set column1='hello' where id<1000
T2:    update table set column1='world' where id>900

如同例10，T1先达，T2马上也到，T1加的排他锁会阻塞T2的update.
  4. 意向锁(Intent Locks) 
    意向锁就是说在屋（好比表明一个表）门口设置一个标识，说明屋子里有人（好比表明某些记录）被锁住了。另外一我的想知道屋子
里是否有人被锁，不用进屋子里一个一个的去查，直接看门口标识就好了。

当一个表中的某一行被加上排他锁后，该表就不能再被加表锁。数据库程序如何知道该表不能被加表锁？一种方式是逐条的判断该
表的每一条记录是否已经有排他锁，另外一种方式是直接在表这一层级检查表自己是否有意向锁，不须要逐条判断。显而后者效率高。

例12：
----------------------------------------
T1:    begin tran
       select * from table (xlock) where id=10  --意思是对id=10这一行强加排他锁
T2:    begin tran
       select * from table (tablock)     --意思是要加表级锁
       
假设T1先执行，T2后执行，T2执行时，欲加表锁，为判断是否能够加表锁，数据库系统要逐条判断table表每行记录是否已有排他锁，
若是发现其中一行已经有排他锁了，就不容许再加表锁了。只是这样逐条判断效率过低了。

实际上，数据库系统不是这样工做的。当T1的select执行时，系统对表table的id=10的这一行加了排他锁，还同时悄悄的对整个表
加了意向排他锁(IX)，当T2执行表锁时，只须要看到这个表已经有意向排他锁存在，就直接等待，而不须要逐条检查资源了。

例13：
----------------------------------------
T1:    begin tran
       update table set column1='hello' where id=1
T2:    begin tran
       update table set column1='world' where id=1

这个例子和上面的例子实际效果相同，T1执行，系统对table同时对行加排他锁、对页加意向排他锁、对表加意向排他锁。
  5. 计划锁(Schema Locks) 
    例14：
----------------------------------------
alter table .... (加schema locks，称之为Schema modification (Sch-M) locks

DDL语句都会加Sch-M锁
该锁不容许任何其它session链接该表。连都连不了这个表了，固然更不用说想对该表执行什么sql语句了。

例15:
----------------------------------------
用jdbc向数据库发送了一条新的sql语句，数据库要先对之进行编译，在编译期间，也会加锁，称之为：Schema stability (Sch-S) locks

select * from tableA

编译这条语句过程当中，其它session能够对表tableA作任何操做(update,delete，加排他锁等等），但不能作DDL(好比alter table)操做。
  6. Bulk Update Locks 主要在批量导数据时用（好比用相似于oracle中的imp/exp的bcp命令）。不难理解，程序员每每也不须要关心，不赘述了。

3 什么时候加锁？ 

如何加锁，什么时候加锁，加什么锁，你能够经过hint手工强行指定，但大可能是数据库系统自动决定的。这就是为何咱们能够不懂锁也可
以高高兴兴的写SQL。

例15:
----------------------------------------
T1:    begin tran
       update table set column1='hello' where id=1
T2:    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED  -- 事务隔离级别为容许脏读
       go
       select * from table where id=1
这里，T2的select能够查出结果。若是事务隔离级别不设为脏读，则T2会等T1事物执行完才能读出结果。

数据库如何自动加锁的？

1) T1执行，数据库自动加排他锁
2) T2执行，数据库发现事务隔离级别容许脏读，便不加共享锁。不加共享锁，则不会与已有的排他锁冲突，因此能够脏读。

例16:
----------------------------------------
T1:    begin tran
       update table set column1='hello' where id=1
T2:    select * from table where id=1 --为指定隔离级别，则使用系统默认隔离级别，它不容许脏读

若是事务级别不设为脏读，则：
1) T1执行，数据库自动加排他锁
2) T2执行，数据库发现事务隔离级别不容许脏读，便准备为这次select过程加共享锁，但发现加不上，由于已经有排他锁了，因此就
   等啊等。直到T1执行完，释放了排他锁，T2才加上了共享锁，而后开始读....

4 锁的粒度

锁的粒度就是指锁的生效范围，就是说是行锁，仍是页锁，仍是整表锁. 锁的粒度一样既能够由数据库自动管理，也能够经过手工指定hint来管理。程序员

例17：
----------------------------------------
T1:    select * from table (paglock)
T2:    update table set column1='hello' where id>10

T1执行时，会先对第一页加锁，读完第一页后，释放锁，再对第二页加锁，依此类推。假设前10行记录刚好是一页(固然，通常不可能
一页只有10行记录），那么T1执行到第一页查询时，并不会阻塞T2的更新。

例18：
----------------------------------------
T1:    select * from table (rowlock)
T2:    update table set column1='hello' where id=10

T1执行时，对每行加共享锁，读取，而后释放，再对下一行加锁;T2执行时，会对id=10的那一行试图加锁，只要该行没有被T1加上行锁，
T2就能够顺利执行update操做。

例19：
----------------------------------------
T1:    select * from table (tablock)
T2:    update table set column1='hello' where id = 10

T1执行，对整个表加共享锁. T1必须彻底查询完，T2才能够容许加锁，并开始更新。

以上3例是手工指定锁的粒度，也能够经过设定事务隔离级别，让数据库自动设置锁的粒度。不一样的事务隔离级别，数据库会有不一样的
加锁策略（好比加什么类型的锁，加什么粒度的锁）。具体请查联机手册。

5 锁与事务隔离级别的优先级 

手工指定的锁优先，
例20:
----------------------------------------
T1:    GO
       SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
       GO
       BEGIN TRANSACTION
       SELECT * FROM table (NOLOCK)
       GO
T2:    update table set column1='hello' where id=10

T1是事物隔离级别为最高级，串行锁，数据库系统本应对后面的select语句自动加表级锁，但由于手工指定了NOLOCK，因此该select
语句不会加任何锁，因此T2也就不会有任何阻塞。

6 数据库的其它重要Hint以及它们的区别 

1) holdlock 对表加共享锁，且事务不完成，共享锁不释放。
2) tablock  对表加共享锁，只要statement不完成，共享锁不释放。
   与holdlock区别，见下例：
   例21
   ----------------------------------------
   T1:
   begin tran
   select * from table (tablock)
   T2:
   begin tran
   update table set column1='hello' where id = 10

   T1执行完select，就会释放共享锁，而后T2就能够执行update. 此之谓tablock. 下面咱们看holdlock
   例22
   ----------------------------------------
   T1:
   begin tran
   select * from table (holdlock)
   T2:
   begin tran
   update table set column1='hello' where id = 10
   
   T1执行完select，共享锁仍然不会释放，仍然会被hold(持有），T2也所以必须等待而不能update. 当T1最后执行了commit或
   rollback说明这一个事务结束了，T2才取得执行权。
  
3) TABLOCKX 对表加排他锁
  
   例23：
   ----------------------------------------
   T1:    select * from table(tablockx) (强行加排他锁）
   其它session就没法对这个表进行读和更新了，除非T1执行完了，就会自动释放排他锁。
   例24：
   ----------------------------------------
   T1:    begin tran
          select * from table(tablockx)
   此次，单单select执行完还不行，必须整个事务完成（执行了commit或rollback后）才会释放排他锁。
  
4) xlock 加排他锁
   那它跟tablockx有何区别呢？

   它能够这样用，
   例25:
   ----------------------------------------
   select * from table(xlock paglock) 对page加排他锁
   而TABLELOCX不能这么用。

   xlock还可这么用：select * from table(xlock tablock) 效果等同于select * from table(tablockx)

7 锁的超时等待

例26sql

SET LOCK_TIMEOUT 4000 用来设置锁等待时间，单位是毫秒，4000意味着等待
4秒能够用select @@LOCK_TIMEOUT查看当前session的锁超时设置。-1 意味着
永远等待。

T1: begin tran
    udpate table set column1='hello' where id = 10
T2: set lock_timeout 4000
    select * from table wehre id = 10

T2执行时，会等待T1释放排他锁，等了4秒钟，若是T1尚未释放排他锁，T2就会抛出异常： Lock request time out period exceeded.数据库

8 附：各类锁的兼容关系表 

| Requested mode                     | IS  | S   | U   | IX  | SIX | X  |
| Intent shared (IS)                 | Yes | Yes | Yes | Yes | Yes | No |
| Shared (S)                         | Yes | Yes | Yes | No  | No  | No |
| Update (U)                         | Yes | Yes | No  | No  | No  | No |
| Intent exclusive (IX)              | Yes | No  | No  | Yes | No  | No |
| Shared with intent exclusive (SIX) | Yes | No  | No  | No  | No  | No |
| Exclusive (X)                      | No  | No  | No  | No  | No  | No |

9 如何提升并发效率

  1. 悲观锁：利用数据库自己的锁机制实现。经过上面对数据库锁的了解，能够根据具体业务状况综合使用事务隔离级别与合理的手工指定锁的方式好比下降锁的粒度等减小并发等待。
  2. 乐观锁：利用程序处理并发。原理都比较好理解，基本一看即懂。方式大概有如下3种
    1. 对记录加版本号.
    2. 对记录加时间戳.
    3. 对将要更新的数据进行提早读取、过后对比。

不管是数据库系统自己的锁机制，仍是乐观锁这种业务数据级别上的锁机制，本质上都是对状态位的读、写、判断。session

 

转载：http://www.cnblogs.com/zhouqianhua/archive/2011/04/15/2017049.html并发

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程