with(nolock) 仍然会申请加锁

with(nolock) table hint 不意味着不会加锁,使用 Trace Flag 1200  返回加锁的整个过程,是学习加锁过程的得力工具

DBCC TRACEON(1200,-1)

DBCC TRACEON(3604) 

DBCC TRACESTATUS

Step1,设置事务隔离级别为 Read Committed,然后使用with(nolock) table hint,查看加锁过程

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

select *
from dbo.test with(nolock)
where id=1

在第一次执行该语句时,加锁过程如下

Process 76 acquiring S lock on DATABASE: 12 [PLANGUIDE] (class bit0 ref1) result: OK
Process 76 releasing lock on DATABASE: 12 [PLANGUIDE]
Process 76 acquiring Sch-S lock on OBJECT: 12:544379958:0  (class bit0 ref1) result: OK
Process 76 releasing lock on OBJECT: 12:544379958:0
Process 76 acquiring S lock on DATABASE: 12 [PLANGUIDE] (class bit0 ref1) result: OK
Process 76 acquiring S lock on DATABASE: 12 [PLANGUIDE] (class bit0 ref1) result: OK
Process 76 acquiring Sch-S lock on OBJECT: 12:560380015:0  (class bit0 ref1) result: OK
Process 76 acquiring Sch-S lock on METADATA: database_id = 12 INDEXSTATS(object_id = 560380015, index_id or stats_id = 0) (class bit0 ref1) result: OK
Process 76 acquiring Sch-S lock on METADATA: database_id = 12 INDEXSTATS(object_id = 560380015, index_id or stats_id = 0) (class bit0 ref1) result: OK
Process 76 releasing lock reference on METADATA: database_id = 12 INDEXSTATS(object_id = 560380015, index_id or stats_id = 0)
Process 76 acquiring X lock on OBJECT: 12:560380015:0 [UPDSTATS] (class bit0 ref1) result: OK
Process 76 releasing lock on OBJECT: 12:560380015:0 [UPDSTATS]
Process 76 acquiring Sch-S lock on METADATA: database_id = 12 INDEXSTATS(object_id = 560380015, index_id or stats_id = 2) (class bit0 ref1) result: OK
Process 76 acquiring Sch-S lock on METADATA: database_id = 12 STATS(object_id = 560380015, stats_id = 2) (class bit0 ref1) result: OK
Process 76 acquiring S lock on KEY: 12:281474980642816 (fa51984d2469) (class bit0 ref1) result: OK
Process 76 releasing lock on METADATA: database_id = 12 INDEXSTATS(object_id = 560380015, index_id or stats_id = 2)
Process 76 releasing lock on METADATA: database_id = 12 STATS(object_id = 560380015, stats_id = 2)
Process 76 releasing lock on METADATA: database_id = 12 INDEXSTATS(object_id = 560380015, index_id or stats_id = 0)
Process 76 releasing lock on OBJECT: 12:560380015:0
Process 76 releasing lock reference on DATABASE: 12 [PLANGUIDE]
Process 76 releasing lock on DATABASE: 12 [PLANGUIDE]
Process 76 acquiring Sch-S lock on OBJECT: 12:560380015:0  (class bit0 ref1) result: OK
Process 76 acquiring S lock on HOBT: 12:72057625107234816 [BULK_OPERATION] (class bit0 ref1) result: OK

(1 row(s) affected)
Process 76 releasing lock on OBJECT: 12:560380015:0 

再次执行查询语句时,加锁过程如下

Process 76 acquiring Sch-S lock on OBJECT: 12:560380015:0  (class bit0 ref1) result: OK

Process 76 acquiring S lock on HOBT: 12:72057625107234816 [BULK_OPERATION] (class bit0 ref1) result: OK

(1 row(s) affected)
Process 76 releasing lock on OBJECT: 12:560380015:0 

使用With(nolock) table hint,至少会申请Schema 和 HoBT 上的共享锁。

To Quota:“WITH (NOLOCK)” doesn’t actually mean no locking.

At some point in your career, you’re going to start using WITH (NOLOCK) on everything because it gets your query results faster.  That’s not necessarily a bad idea, but it can come with some surprising side effects that Kendra discusses in her “There’s Something About Nolock” video.  I’m going to focus on one of them here, though.

When you query a table – even WITH (NOLOCK) – you take out a schema stability lock.  No one else can change that table or indexes until your query is finished.  That doesn’t sound like a big deal until you need to drop an index, but you can’t because people are constantly querying a table, and they think there’s no overhead as long as they use WITH (NOLOCK).

There’s no silver bullet here, but start by reading about SQL Server’s isolation levels – I bet READ COMMITTED SNAPSHOT ISOLATION is an even better choice for your app.  It gets you consistent data with less blocking hassles.

时间: 2024-11-29 08:42:29

with(nolock) 仍然会申请加锁的相关文章

高性能MySQL --- 读书笔记(2) - 2016/8/2

第1章 MySQL架构 MySQL架构与其他数据库服务器大不相同,这使它能够适应广泛的应用.MySQL足够灵活,能适应高要求架构.例如Web应用,同时还适用于嵌入式应用.数据仓库.内容索引和分发软件.高可用的冗余系统.联机事务处理系统OLTP及很多其他应用类型. 为了充分发挥MySQL的性能,顺畅地使用它,就必须理解它的设计.MySQL的灵活性体现在很多方面,它可以再众多硬件平台上良好的配置和运行,还支持多种数据类型.不过MySQL最重要.最不同寻常的特征是它的存储引擎框架,这种架构可以讲查询处

北大SQL数据库视频课程笔记

Jim Gray - Transaction processing: concepts and techniqueshttp://research.microsoft.com/~gray/ 事务概念 事务定义- 事务是由一系列操作序列构成的程序执行单元,这些操作要么都做,要么都不做,是一个不可分割的工作单位. 事务特性(ACID)* 原子性(Atomicity)事务中包含的所有操作要么全做,要么全不做,原子性由恢复机制实现. * 一致性(Consistency)事务的隔离执行必须保证数据库的一致

为什么乐观锁效率高于悲观锁?(转,该文章没有给出满意回答)

add by zhj: 这个问题最后没有给出另人满意的答案,我跟提问人有相同的困惑.另外,可参见MySQL事务隔离级别,锁 原文:为什么乐观锁效率高于悲观锁? 标 题: [合集]为什么乐观锁效率高于悲观锁? 发信站: 饮水思源 (2008年05月19日12:29:00 星期一), 站内信件 ☆──────────────────────────────────────☆ magiczhang (梅西,未来之王) 于 2008年05月14日21:13:24 星期三) 提到: 书上都说如果是长事务高

Android 电源管理 -- wakelock机制

转载地址:http://blog.csdn.net/wh_19910525/article/details/8287202 Wake Lock是一种锁的机制, 只要有人拿着这个锁,系统就无法进入休眠, 可以被用户态程序和内核获得. 这个锁可以是有超时的 或者 是没有超时的, 超时的锁会在时间过去以后自动解锁.如果没有锁了或者超时了, 内核就会启动休眠的那套机制来进入休眠. PowerManager.WakeLock 有加锁和解锁两种状态,加锁的方式有两种: 第一种是永久的锁住,这样的锁除非显式的

Android wakelock机制

Wake Lock是一种锁的机制, 只要有人拿着这个锁,系统就无法进入休眠,可以被用户态程序和内核获得. 这个锁可以是有超时的或者是没有超时的,超时的锁会在时间过去以后自动解锁. 如果没有锁了或者超时了, 内核就会启动休眠的那套机制来进入休眠. PowerManager.WakeLock 有加锁和解锁两种状态,加锁的方式有两种,一种是永久的锁住,这样的锁除非显式的放开,是不会解锁的,所以这种锁用起来要非常的小心.第二种锁是超时锁,这种锁会在锁住后一段时间解锁. 在创建了 PowerManager

nfs 服务的安装及配置

此处声明 : 实验环境为 Centos 6.5 nfs  服务器端: nfs-utils 一般默认安装 (如果没有安装的话 :  yum install  -y  nfs-utils ) 生成的主要文件为 : (  可以用 rpm -ql nfs-utils 查看) /usr/sbin/rpc.mountd /usr/sbin/rpc.nfsd 启动服务 : service nfs start 注意启动之前请先确保 rpcbind 启动(service rpcbind start | statu

MDL--元数据锁的锁请求与锁等待+元数据锁类对象

1 元数据锁的锁请求与锁等待 元数据锁在MySQL Server层,按照锁的状态被细分为两种,一种是已经施加的锁,一种是等待施加的锁即锁请求,这样被区分的原因,如MySQL对"class MDL_request"的代码注释作了解释: /** A pending metadata lock request. A lock request and a granted metadata lock are represented by different classes because the

pthread的各种同步机制

https://casatwy.com/pthreadde-ge-chong-tong-bu-ji-zhi.html pthread是POSIX标准的多线程库,UNIX.Linux上广泛使用,windows上也有对应的实现,所有的函数都是pthread打头,也就一百多个函数,不是很复杂.然而多线程编程被普遍认为复杂,主要是因为多线程给程序引入了一定的不可预知性,要控制这些不可预知性,就需要使用各种锁各种同步机制,不同的情况就应该使用不同的锁不同的机制.什么事情一旦放到多线程环境,要考虑的问题立刻

iOS 常见知识点(三):Lock

iOS 常见知识点(一):Runtime iOS 常见知识点(二):RunLoop 锁是最常用的同步工具.一段代码段在同一个时间只能允许被有限个线程访问,比如一个线程 A 进入需要保护代码之前添加简单的互斥锁,另一个线程 B 就无法访问,只有等待前一个线程 A 执行完被保护的代码后解锁,B 线程才能访问被保护代码. iOS 中的八大锁 NSLock @protocol NSLocking - (void)lock; - (void)unlock; @end @interface NSLock :