lock in database

1 Preface

The performance of deadlocks and locks should be considered for large concurrent operations of the database. I see that most of the words on the Internet are unclear (especially update locks), so here is a brief explanation for the convenience of the following description. Here, T1 represents a database execution request, and T2 represents another request. It can also be understood that T1 is a thread, and T2 is another a thread. T3, T4 and so on. Take SQL Server (2005) as an example below.

2 types of locks

Shared lock.

Example 1:
----------------------------------------
T1: select * from table (please imagine that it takes 1 hour to execute, please imagine the following sql statements)
T2: update table set column1='hello'

Process:

T1 runs (plus shared lock)
T2 run
If T1 has not finished executing
T2 etc...
else
lock is released
T2 execution
endif

The reason why T2 has to wait is because T2 tries to add an exclusive lock to the table table before executing the update.
The database stipulates that shared locks and exclusive locks cannot coexist on the same resource at the same time. So T2 has to wait for T1
After the execution is completed, the shared lock is released, and the exclusive lock can be added, and then the update statement can be executed.

Example 2:
----------------------------------------
T1: select * from table
T2: select * from table

Here, T2 does not need to wait for T1 to finish executing, but can be executed immediately.

analyze:
When T1 runs, the table is locked, such as lockA
T2 runs, and then adds a shared lock to the table, such as lockB.

Two locks can exist on the same resource (such as the same table) at the same time. This is called a common
Shared locks are compatible with shared locks. This means that shared locks do not prevent other sessions from reading resources at the same time, but prevent
Stop other session update

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

This time, T2 can run without waiting for T1 to finish running, but T3 can run until both T1 and T2 have finished running.
Because T3 must wait for the shared locks of T1 and T2 to be released before adding exclusive locks and then executing update
operate.

Example 4: (occurrence of deadlock)
----------------------------------------
T1:
begin tran
select * from table (holdlock) (holdlock means adding a shared lock, which is not released until the end of the transaction)
update table set column1='hello'

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

Assuming that T1 and T2 reach select at the same time, T1 adds a shared lock to the table, and T2 also adds a shared lock. When
When the select of T1 is executed and the update is ready to be executed, according to the lock mechanism, the shared lock of T1 needs to be upgraded.
The next update can be executed only after the exclusive lock is upgraded. Before upgrading the exclusive lock, you must wait for the update on the table.
Other shared locks are released, but because shared locks such as holdlock are only released after the transaction ends,
Therefore, because the shared lock of T2 is not released, T1 waits (wait for T2 to release the shared lock, and it is better to upgrade it into a row).
other locks), for the same reason, it also causes T2 and so on because the shared lock of T1 is not released. A deadlock occurs.

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

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

Although this kind of statement is the most common, many people think that it has the opportunity to cause deadlock, but in fact it depends on the situation.
In this case, if id is the primary key and there is an index on it, then T1 will find the record at once (the record with id=10).
record), and then add an exclusive lock to the record, T2, similarly, locate the record through the index all at once,
Then add an exclusive lock to the record with id=20, so that each update of T1 and T2 will not affect each other. Neither does T2
Need to wait.

But if id is a normal column, there is no index. Then when T1 adds an exclusive lock to the row with id=10,
In order to find id=20, T2 needs to scan the full table, then it will add a shared lock or update to the table in advance
lock or exclusive lock (depending on the database execution strategy and method, such as the first execution and the second execution
The database execution strategy will be different). But because T1 has added an exclusive lock to a record, resulting in
The full table scan of T2 cannot go on, causing T2 to wait.

How to solve the deadlock? One way is as follows:
Example 6:
----------------------------------------
T1:
begin tran
select * from table(xlock) (xlock means adding an exclusive lock directly to the table)
update table set column1='hello'

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

In this way, when T1's select is executed, an exclusive lock is directly added to the table. When T2 executes the select, it needs to wait for the T1 transaction to be completely executed before it can be executed. Deadlocks are ruled out.
But when the third user comes over and wants to execute a query statement, it has to wait because of the existence of the exclusive lock, and the fourth and fifth users will also wait because of this. in large concurrency
In this case, it is too friendly to let everyone wait, so an update lock is introduced here.

Update lock

In order to solve the deadlock, the update lock is introduced.

Example 7:
----------------------------------------
T1:
begin tran
select * from table(updlock) (plus update lock)
update table set column1='hello'
T2:
begin tran
select * from table(updlock)
update table set column1='world'

The update lock means: "I just want to read now, others can read it, but I may do update operations in the future, I have acquired from shared locks (for reading) to exclusive locks
(to update)". Only one update lock for a thing can qualify for this.

T1 executes select and adds an update lock.
T2 is running, ready to add an update lock, but finds that there is already an update lock there, and has to wait.

When user3, user4... need to query the data in the table table later, it will not be blocked because the select of T1 is being executed, and it can still be queried. Compared with Example 6, this improves the
efficiency.

Example 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，发现已有更新锁，则等待，后面步骤就跟第一种情况一样了。

这个例子是说明：排他锁与更新锁是不兼容的，它们不能同时加在同一子资源上。

排他锁（独占锁，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.

意向锁(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同时对行家排他锁、对页加意向排他锁、对表加意向排他锁。

计划锁(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)操作。

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 锁的超时等待

例26

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 如何提高并发效率

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

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