sqlserver默认锁,sqlserver 乐观锁

如何掌握SQLServer的锁机制

SQL SERVER里的锁机制：

NOLOCK（不加锁）

此选项被选中时，SQL Server 在读取或修改数据时不加任何锁。 在这种情况下，用户有可能读取到未完成事务（Uncommited Transaction）或回滚(Roll Back)中的数据, 即所谓的“脏数据”。

HOLDLOCK（保持锁）

此选项被选中时，SQL Server 会将此共享锁保持至整个事务结束，而不会在途中释放。 例如，“ SELECT * FROM my_table HOLDLOCK”就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。

UPDLOCK（修改锁）

此选项被选中时，SQL Server 在读取数据时使用修改锁来代替共享锁，并将此锁保持至整个事务或命令结束。使用此选项能够保证多个进程能同时读取数据但只有该进程能修改数据。

TABLOCK（表锁）

此选项被选中时，SQL Server 将在整个表上置共享锁直至该命令结束。 这个选项保证其他进程只能读取而不能修改数据。

PAGLOCK（页锁）

此选项为默认选项， 当被选中时，SQL Server 使用共享页锁。

TABLOCKX（排它表锁）

此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。

sql里的事务语句 默认都有加数据锁的么？

就sqlserver数据库而言，每一条语句在默认事务级别下（可提交读级别）都是加锁的

如一条普通的查询，要加S锁（共享），一个更新要加U锁（更新）等等

你说的表锁、行锁只是锁的粗粒程度，如字面意思，行锁是锁住几行，表锁就是锁住整个表所在的全部数据页

sqlserver锁表机制

这个问题要具体分析：

第一，事务隔离级别基本两种模式，一种是阻塞式（read committed，repeatable read，serializable）

，一种是非阻塞式(read uncommitted,snapshot)。

默认是read committed，这种情况一般在更新表的时候，如果不使用hint 提示，基本是先对表添加IX锁，级别不算高，基本和其他锁兼容，但是repeatable read，serializable 事务隔离级别就会先对表添加IX锁，然后向X锁转化，而X锁和大多数锁都不兼容，容易发生表阻塞。

第二种隔离级别不会有以上问题，但是又引入了其它的问题。

以上是一种情况。

另外一种就是 锁升级，一个锁是96B内存，如果太多，sqlserver就会升级为表锁，一般是5000以上行级锁就升级为一个表X锁。

所以适当的文件分组和表分区 是有必要的。

其次就是资源互相引用导致事务长时间不能释放，导致真正的死锁，不过SQL2005以后，这种情况发生的概率很低。

留个问题你自己去想。

两个SQL，两个连接，同时执行。

update A set A.NAME=xxx where A.id=55

update A set A.NAME=xxx where A.id=56, 如果 56 不存在你说会发生什么情况呢？

.net的sqlserver事务里，delete语句如何只锁行，不锁表

你理解错了！

默认sqlserver都是行数据锁定，隔离级别是 read commited 也就是读取可 提交数据。

我给你举个例子！

SELECT TOP 1000

[ID]

,[DeleteBy]

,[DelDate]

FROM [dbo].[DeleteLog]

显示结果

-----------------------------------------------

ID DeleteBy DelDate

1 admin 2008-04-13 00:00:00.000

2 admin 2008-05-04 00:00:00.000

-------------------------------------------------

表数据就两行

然后我做如下操作：

打开 SQL Server Management Studio

输入：

begin transaction

DELETE FROM [HMS].[dbo].[DeleteLog]

where ID='1'

在另一个窗口中：

SELECT

[ID]

,[DeleteBy]

,[DelDate]

FROM [dbo].[DeleteLog]

where ID=1

你发现 这一个窗口被阻塞了，

但是查询

SELECT

[ID]

,[DeleteBy]

,[DelDate]

FROM [dbo].[DeleteLog]

where ID=2

可以正确返回结果。 这充分证明了，sqlserver默认隔离级别是行数据锁定。

然后你此时在第一个删除窗口 中输入

rollback

，记住前面的删除不执行，只执行rollback。

此时看一下查询

SELECT

[ID]

,[DeleteBy]

,[DelDate]

FROM [dbo].[DeleteLog]

where ID=1

那个窗口的结果已经出来了，阻塞被解除了。

========================================

当然了！你执行了全表检索肯定也是被阻塞的，因为删除操作还没提交啊，检索数据中又包含了你要删除的数据，当然被阻塞了。

你的问题出现在哪里了，你应该明白了吧！

解决这个问题其实很简单，不要长事务占用。检索的时候避开要删除的数据。

当然也可以改变隔离级别，sqlserver分为两类隔离级别，改成非阻塞类就可以。

但是我个人不推荐这么做。改变隔离级别可以如下方式：

set transaction isolation level read uncommitted

begin transaction

DELETE FROM [HMS].[dbo].[DeleteLog]

where ID='1'

这个删除没有提交

检索的时候

set transaction isolation level read uncommitted

SELECT

[ID]

,[DeleteBy]

,[DelDate]

FROM [dbo].[DeleteLog]

where ID=1

根本不会阻塞。 比较顺利，删除更新也一样。

这种方式 适合 数据量庞大的社交，天文数据库，企业管理不适合。

可以从侧面看出，你的程序并不优良，明白了否？