例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也会因此而等待。在大并发

情况下，让大家等待显得性能就太友好了，所以，这里引入了更新锁。