你所说的也就是乐观锁定和悲观锁定.1.乐观锁定.使用timestamp列.在更新数据的时候,要检查timestamp列的值是否发生了变化.2.悲观锁定.在查询表的时候就加上UPDLOCK,防止在更新之前有人更新了数据.如下:begin trans select * from 表 with(updlock) where id=1 ................. update 表 set name='chen' where id=1commit transGo
如果只讨论列值是否受更新的影响.则答案是肯定的, 即update会影响timestamp列值, 下面是示例DECLARE @t TABLE( id int, timestamp)INSERT @t(id) VALUES(1) SELECT * FROM @t UPDATE @t SET id = 2 SELECT * FROM @t-- 结果: id timestamp ----------- ------------------ 1 0x00000000000007D4(1 行受影响) id timestamp ----------- ------------------ 2 0x00000000000007D5(1 行受影响)
-- 延迟50秒,模拟并发访问. waitfor delay '000:00:50' -- 把刚才选择出来的卡进行注册. update Card set F_Name=user, F_Time=getdate(), F_Flag=1 where F_CardNo=@CardNocommit问题:如果我们在同一窗口执行同一段代码,但是去掉了waitfor delay子句.两边执行完毕后 我们发现尽管执行了两次注册,但是只注册了一张卡,也就是两个人注册了同一张卡. 悲观锁定解决方案-- 我们只要对上边的代码做微小的改变就可以实现悲观的锁定.declare @CardNo varchar(20) Begin Tran -- 选择一张未使用的卡 select top 1 @CardNo=F_CardNo from Card with (UPDLOCK) where F_Flag=0
-- 延迟50秒,模拟并发访问. waitfor delay '000:00:50' -- 把刚才选择出来的卡进行注册. update Card set F_Name=user, F_Time=getdate(), F_Flag=1 where F_CardNo=@CardNocommit注意其中的区别了吗?with(updlock),是的,我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对次记录进行更新.注意更新锁和共享锁是不冲突的,也就是其他用户还可以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.如果我们在另外一个窗口执行此代码,同样不加waifor delay子句.两边执行完毕后,我们发现成功的注册了两张卡.可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候,其他更新用户必须排队等待,即使那个用户更新的不是同一条记录.乐观锁定解决方案-- 首先我们在Card表里边加上一列F_TimeStamp 列,该列是varbinary(8)类型.但是在更新的时候这个值会自动增长.alter table Card add F_TimeStamp timestamp not null -- 悲观锁定 declare @CardNo varchar(20) declare @timestamp varbinary(8) declare @rowcount intBegin Tran -- 取得卡号和原始的时间戳值 select top 1 @CardNo=F_CardNo, @timestamp=F_TimeStamp from Card where F_Flag=0
-- 延迟50秒,模拟并发访问. waitfor delay '000:00:50' -- 注册卡,但是要比较时间戳是否发生了变化.如果没有发生变化.更新成功.如果发生变化,更新失败. update Card set F_Name=user, F_Time=getdate(), F_Flag=1 where F_CardNo=@CardNo and F_TimeStamp=@timestamp set @rowcount=@@rowcount if @rowcount=1 begin print '更新成功!' commit end else if @rowcount=0 begin if exists(select 1 from Card where F_CardNo=@CardNo) begin print '此卡已经被另外一个用户注册!' rollback tran end else begin print '并不存在此卡!' rollback tran end end在另外一个窗口里边执行没有waitfor的代码,注册成功后,返回原来的窗口,我们就会发现到时间后它显示的提示是此卡以被另外一个用户注册的提示.很明显,这样我们也可以避免两个用户同时注册一张卡的现象的出现.同时,使用这种方法的另外一个好处是没有使用更新锁,这样增加的系统的并发处理能力.
每个数据库都有一个计数器,当对数据库中包含 timestamp 列的表执行插入或更新操作时,该计数器值就会增加。该计数器是数据库时间戳。这可以跟踪数据库内的相对时间,而不是时钟相关联的实际时间。一个表只能有一个 timestamp 列。每次修改或插入包含 timestamp 列的行时,就会在 timestamp 列中插入增量数据库时间戳值。这一属性使 timestamp 列不适合作为键使用,尤其是不能作为主键使用。对行的任何更新都会更改 timestamp 值,从而更改键值。如果该列属于主键,那么旧的键值将无效,进而引用该旧值的外键也将不再有效。如果该表在动态游标中引用,则所有更新均会更改游标中行的位置。如果该列属于索引键,则对数据行的所有更新还将导致索引更新。使用某一行中的 timestamp 列可以很容易地确定该行中的任何值自上次读取以后是否发生了更改。如果对行进行了更改,就会更新该时间戳值。如果没有对行进行更改,则该时间戳值将与以前读取该行时的时间戳值一致。若要返回数据库的当前时间戳值,请使用 @@DBTS。Transact-SQL timestamp 数据类型不同于在 SQL-2003 标准中定义的 timestamp 数据类型。SQL-2003 timestamp 数据类型等同于 Transact-SQL datetime 数据类型。rowversion 的数据类型为 timestamp 数据类型的同义词,并具有数据类型同义词的行为。在 DDL 语句,请尽量使用 rowversion 而不是 timestamp。有关详细信息,请参阅 数据类型同义词 (Transact-SQL)。在 CREATE TABLE 或 ALTER TABLE 语句中,不必为 timestamp 数据类型指定列名,例如: 复制代码
CREATE TABLE ExampleTable (PriKey int PRIMARY KEY, timestamp);
如果不指定列名,则 Microsoft SQL Server 2005 数据库引擎 将生成 timestamp 列名;
id int,
timestamp)INSERT @t(id) VALUES(1)
SELECT * FROM @t
UPDATE @t SET id = 2
SELECT * FROM @t-- 结果:
id timestamp
----------- ------------------
1 0x00000000000007D4(1 行受影响)
id timestamp
----------- ------------------
2 0x00000000000007D5(1 行受影响)
乐观锁定,悲观锁定,锁在实际的多用户并发访问的生产环境里边,我们经常要尽可能的保持数据的一致性。而其中
最典型的例子就是我们从表里边读取数据,检查验证后对数据进行修改,然后写回到数据库
中。在读取和写入的过程中,如果在多用户并发的环境里边,其他用户已经把你要修改的数据
进行了修改是非常有可能发生的情况,这样就造成了数据的不一致性。解决这样的办法,SQL SERVER
提出了乐观锁定和悲观锁定的概念,下边我以一个实例来说明如何使用乐观锁定和悲观锁定来
解决这样的问题。
/* 建立测试表:Card,代表一个真实的卡库,供用户注册.用户要从里边选出一个未使用的卡,也就是F_Flag=0的卡,给用户注册:更新F_Name,F_Time,F_Flag字段. 如果出现两个用户同时更新一张卡的情况,是不能容忍的,也就是我们所说的数据不一致行。*/create table Card(F_CardNO varchar(20),F_Name varchar(20),F_Flag bit,F_Time datetime)
Go
insert Card(F_CardNo,F_Flag) select '1111-1111',0
insert Card(F_CardNo,F_Flag) select '1111-1112',0
insert Card(F_CardNo,F_Flag) select '1111-1113',0
insert Card(F_CardNo,F_Flag) select '1111-1114',0
insert Card(F_CardNo,F_Flag) select '1111-1115',0
insert Card(F_CardNo,F_Flag) select '1111-1116',0
insert Card(F_CardNo,F_Flag) select '1111-1117',0
insert Card(F_CardNo,F_Flag) select '1111-1118',0
insert Card(F_CardNo,F_Flag) select '1111-1119',0
insert Card(F_CardNo,F_Flag) select '1111-1110',0
Go-- 下边是我们经常使用的更新方案如下:
declare @CardNo varchar(20)
Begin Tran -- 选择一张未使用的卡
select top 1 @CardNo=F_CardNo
from Card where F_Flag=0
-- 延迟50秒,模拟并发访问.
waitfor delay '000:00:50' -- 把刚才选择出来的卡进行注册. update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNocommit问题:如果我们在同一窗口执行同一段代码,但是去掉了waitfor delay子句.两边执行完毕后 我们发现尽管执行了两次注册,但是只注册了一张卡,也就是两个人注册了同一张卡. 悲观锁定解决方案-- 我们只要对上边的代码做微小的改变就可以实现悲观的锁定.declare @CardNo varchar(20)
Begin Tran -- 选择一张未使用的卡
select top 1 @CardNo=F_CardNo
from Card with (UPDLOCK) where F_Flag=0
-- 延迟50秒,模拟并发访问.
waitfor delay '000:00:50' -- 把刚才选择出来的卡进行注册. update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNocommit注意其中的区别了吗?with(updlock),是的,我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对次记录进行更新.注意更新锁和共享锁是不冲突的,也就是其他用户还可以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.如果我们在另外一个窗口执行此代码,同样不加waifor delay子句.两边执行完毕后,我们发现成功的注册了两张卡.可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候,其他更新用户必须排队等待,即使那个用户更新的不是同一条记录.乐观锁定解决方案-- 首先我们在Card表里边加上一列F_TimeStamp 列,该列是varbinary(8)类型.但是在更新的时候这个值会自动增长.alter table Card add F_TimeStamp timestamp not null
-- 悲观锁定
declare @CardNo varchar(20)
declare @timestamp varbinary(8)
declare @rowcount intBegin Tran -- 取得卡号和原始的时间戳值
select top 1 @CardNo=F_CardNo,
@timestamp=F_TimeStamp
from Card
where F_Flag=0
-- 延迟50秒,模拟并发访问.
waitfor delay '000:00:50' -- 注册卡,但是要比较时间戳是否发生了变化.如果没有发生变化.更新成功.如果发生变化,更新失败. update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNo and F_TimeStamp=@timestamp
set @rowcount=@@rowcount
if @rowcount=1
begin
print '更新成功!'
commit
end
else if @rowcount=0
begin
if exists(select 1 from Card where F_CardNo=@CardNo)
begin
print '此卡已经被另外一个用户注册!'
rollback tran
end
else
begin
print '并不存在此卡!'
rollback tran
end
end在另外一个窗口里边执行没有waitfor的代码,注册成功后,返回原来的窗口,我们就会发现到时间后它显示的提示是此卡以被另外一个用户注册的提示.很明显,这样我们也可以避免两个用户同时注册一张卡的现象的出现.同时,使用这种方法的另外一个好处是没有使用更新锁,这样增加的系统的并发处理能力.