现在，假设我们按聚集索引查询某行或几行数据（如下图），此时相应的行数据将加上共享锁(S)，而该行数据所在的页、表，将加上意向共享锁(IS)（排它锁或更新锁同理）。而进程对能对同一个资源同时只能持有一个锁，所有只能释放共享锁(S)，再加上排它锁(X)，如果直接释放，资源可能被其他进程夺走，这种方法不是好的处理方式。类似地，当进程对表具有共享锁(S)并在该表的行上具有更新锁(U)时会发生共享意向更新(SIU)，而当进程对表具有更新锁(U)而对行具有排他锁时会发生更新意向排他(UIX)。意向排他共享 (SIX)

SQL Server 闩锁是一种内部的 SQL Server 机制，用于保护共享内存资源，比如缓冲池中的页面和内存数据结构，以便协调对这些资源的访问并保护它们免受破坏。在执行增长和收缩操作时，SQL Server 获取 FCB、FGCB_ADD_REMOVE 和 FGCB_ALLOC 这类闩锁，以确保对文件控制块的访问，并确保对存储在文件组中的信息同步访问。闩锁争用对于拥有大量 CPU 的系统来说是一种常见的情况，它在相同的内存结构上，多个线程同时尝试获取彼此不兼容的 SQL Server 闩锁的结果。

在SQL Server 2014之前， SQL Server提交事务是一个同步的过程，也就是说，只有当SQL Server将该事务相对应的日志记录写入到了磁盘文件之后，才会返回事务提交成功的信号。延迟持久事务提交是异步的，无需等待事务日志写入磁盘就直接返回事务提交成功的信号，I/O操作在后台会以异步的方式写入到数据库事务日志文件中。

方法一：打开profiler跟踪事件 locks: deadlock graph方法二：打开1222或者1204标志记录死锁,在sqlserver日志查看DBCC TRACEON(1222,-1) DBCC TRACEON(1204,-1)如果日志太多就不好找了，这时可以用系统扩展存储过程筛选！--查看是否死锁，确定死锁的的

--当前锁请求情况exec sp_lockselect req_spid,case req_status when 1 then '已授予' when 2 then '正在转换' when 3 then '正在等待' end as req_status,case rsc_type when 1 then 'NULL 资源（未使用）' when 2 then '数据库' when 3 th

SQLserver 2012 增加了新的功能特性 throw ，一直没测试过，这两天又重新整理测试。更多概念可以参考：数据库引擎错误严重性对于sql语句的异常，SqlServer 有 0~25 的严重级别定义：0~10 ：轻微级别11~18：一般级别19~25：严重级别还想测试容易理解：测试一：-- 创建临时表方便测试-

IF (OBJECT_ID('AA','U') IS NOT NULL)DROP TABLE AACREATE TABLE AA(ID INT)SELECT * FROM AA--注：数据库当前只存在表AA，无表#BB和表BB------------------------------------------------------------------------------

说明：很多交易的系统都需要单据号，而单据号按顺序并发获取又是一件头疼的事！~ 一般单据号格式为：前缀+日期+编号（如：KK20150501000001） 现在模拟测试，数据库中的单据号作为一张表处理。数据库单据号表（Billnumber）存储每个账号及其最大的单据号总共一条记录单据号是组合而成的字符串，后位为序号（如：）获取单据号的存储过程：EXEC [

--首先，开启死锁跟踪一段时间DBCC TRACEON(1222,-1)DBCC TRACESTATUS日志记录的死锁信息如图，只是其中的一个死锁信息：现在不分析死锁，分析参与死锁的那些进程信息和死锁的对象信息。--搜索当前日志中参与死锁的进程信息（第一个参数代表日志，现在查看2个日志）exec xp_readerrorlog 0,1,'process i

--查了当前数据库是事务隔离级别DBCC USEROPTIONS【测试一：丢失更新】--事务1begin tran select * from dbo.Test(nolock) where name = 'kk' waitfor delay '00:00:05' update T set info = 'A更改' from Test T(nolock) where name

/*闩锁:当数据页从磁盘读取前，数据库引擎会先在内存中预留适当是内存页，给这些内存加闩锁，数据才能顺利地读到内存。（如果一个线程没法立即获得闩锁，线程则等待，让CPU给其他线程使用） 自旋锁:与闩锁类型的概念.不同闩锁的是:如果一个线程没法立即获得自旋锁，线程则开始轮询，重复检查资源是否可用以继续使用.当然页不会长时间轮询,不久就会让出CPU给其他线程使用.*/DBCC S

-- 测试代码-- DROP TABLE TestCREATE TABLE Test( id INT, name VARCHAR(20), info VARCHAR(20),)CREATE CLUSTERED INDEX IX_Test ON DBO.Test(id)CREATE NONCLUSTERED INDEX IX_Test_name ON DBO.Test(name

--测试示例：CREATE TABLE mytest ( id INT, name VARCHAR(20), info VARCHAR(20), ) INSERT INTO mytest VALUES(1,'kk',null),(2,'mm',null) --【现在测试只有非聚集索引的】CREATE NONCLUSTER

锁粒度：资源格式说明DATABASE不适用resource_database_id 列中已提供数据库 ID。FILE此资源所表示的文件 ID。Object此资源所表示的对象 ID。 此对象可以是sys.objects 中列出的任何对象，不仅仅是表。PAGE:HoBt ID。此值与 sys.p

【对锁机制的研究要具备两个条件：】----------------------------------------1．数据量大2．多个用户同时并发如果缺少这两个条件，数据库不容易产生死锁问题。如果具备这两个条件，则数据库使用中可能存在以下问题：1）丢失更新 两个用户同时对数据进行修改,其中一个用户修改提交后，另一个用户再提交，结果破坏了另一个修改结果。2）脏读 A用户修改了数据时,

--打开跟踪EXEC sp_configure 'show advanced options',1GORECONFIGUREGOEXEC sp_configure 'blocked process threshold',5GO RECONFIGUREGOEXEC sp_configure--授予权限use master grant alter trace to logNa