概述

数据库大并发操作要考虑死锁和锁的性能问题。看到网上大多说的不是很清楚(尤其更新锁），综合整理后分享给大家。

PS:这里用T1代表一个数据库执行请求，T2代表另一个请求，也可以理解为T1为一个线程，T2 为另一个线程。T3,T4以此类推。

锁的种类

1、共享锁(Shared lock)。

例1：----------------------------------------T1: select * from table (请想象它需要执行1个小时之久，后面的sql语句请都这么想象）T2: update table set column1='hello'过程：T1运行 （加共享锁)T2运行If T1 还没执行完 T2等......else 锁被释放 T2执行endifT2之所以要等，是因为T2在执行update前，试图对table表加一个排他锁，而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1执行完，释放了共享锁，才能加上排他锁，然后才能开始执行update语句。例2：----------------------------------------T1: select * from tableT2: select * from table这里T2不用等待T1执行完，而是可以马上执行。分析：T1运行，则table被加锁，比如叫lockAT2运行，再对table加一个共享锁，比如叫lockB。两个锁是可以同时存在于同一资源上的（比如同一个表上）。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源，但阻止其它session update例3：----------------------------------------T1: select * from tableT2: select * from tableT3: update table set column1='hello'这次，T2不用等T1运行完就能运行，T3却要等T1和T2都运行完才能运行。因为T3必须等T1和T2的共享锁全部释放才能进行加排他锁然后执行update操作。例4：（死锁的发生）----------------------------------------T1:begin transelect * from table (holdlock) (holdlock意思是加共享锁，直到事物结束才释放)update table set column1='hello'T2:begin transelect * 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等。死锁产生了。

2、更新锁(Update lock)

为解决死锁，引入更新锁。例5：----------------------------------------T1:begin transelect * from table(updlock) (加更新锁)update table set column1='hello'T2:begin transelect * from table(updlock)update table set column1='world'更新锁的意思是：“我现在只想读，你们别人也可以读，但我将来可能会做更新操作，我已经获取了从共享锁（用来读）到排他锁（用来更新）的资格”。一个事物只能有一个更新锁获此资格。T1执行select，加更新锁。T2运行，准备加更新锁，但发现已经有一个更新锁在那儿了，只好等。当后来有user3、user4...需要查询table表中的数据时，并不会因为T1的select在执行就被阻塞，照样能查询，相比起例6，这提高了效率。例6:----------------------------------------T1: select * from table(updlock) (加更新锁）T2: select * from table(updlock) (等待，直到T1释放更新锁，因为同一时间不能在同一资源上有两个更新锁）T3: select * from table (加共享锁，但不用等updlock释放，就可以读）这个例子是说明：共享锁和更新锁可以同时在同一个资源上。这被称为共享锁和更新锁是兼容的。

3、排他锁（独占锁，Exclusive Locks)

这个简单，即其它事务既不能读，又不能改排他锁锁定的资源。例7T1: update table set column1='hello' where id<1000T2: update table set column1='world' where id>1000假设T1先达，T2随后至，这个过程中T1会对id<1000的记录施加排他锁.但不会阻塞T2的update。例8 (假设id都是自增长且连续的）T1: update table set column1='hello' where id<1000T2: update table set column1='world' where id>900

4、意向锁(Intent Locks)

意向锁就是说在屋（比如代表一个表）门口设置一个标识，说明屋子里有人（比如代表某些记录）被锁住了。另一个人想知道屋子里是否有人被锁，不用进屋子里一个一个的去查，直接看门口标识就行了。当一个表中的某一行被加上排他锁后，该表就不能再被加表锁。数据库程序如何知道该表不能被加表锁？一种方式是逐条的判断该表的每一条记录是否已经有排他锁，另一种方式是直接在表这一层级检查表本身是否有意向锁，不需要逐条判断。显然后者效率高。例9：----------------------------------------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执行表锁时，只需要看到这个表已经有意向排他锁存在，就直接等待，而不需要逐条检查资源了。例10：----------------------------------------T1: begin tran update table set column1='hello' where id=1T2: begin tran update table set column1='world' where id=1这个例子和上面的例子实际效果相同，T1执行，系统对table同时对行家排他锁、对页加意向排他锁、对表加意向排他锁。

5、计划锁(Schema Locks)

例11：----------------------------------------alter table .... (加schema locks，称之为Schema modification (Sch-M) locksDDL语句都会加Sch-M锁该锁不允许任何其它session连接该表。连都连不了这个表了，当然更不用说想对该表执行什么sql语句了。例12:----------------------------------------用jdbc向数据库发送了一条新的sql语句，数据库要先对之进行编译，在编译期间，也会加锁，称之为：Schema stability (Sch-S) locksselect * from tableA编译这条语句过程中，其它session可以对表tableA做任何操作(update,delete，加排他锁等等），但不能做DDL(比如alter table)操作。Bulk Update Locks 主要在批量导数据时用（比如用类似于oracle中的imp/exp的bcp命令）。

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

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

后面会更多分享DBA内容，感兴趣的朋友可以关注下！