Sqlserver死锁语句解释；

https://blog.csdn.net/weixin_33877885/article/details/94532161

SPID:SQL Server进程ID号，

KPID:内核进程ID;线程ID

Blocked:引起阻塞的SPID;

waitTime:等待时间，单位是毫秒；

重点介绍几个耗时最高的锁含义：

　 LCK_M_IX：正在等待获取意向排它锁。在增删改查中都会有涉及到意向排它锁。
　　LCK_M_U：正在等待获取更新锁。在修改删除都会有涉及到更新锁。
　　LCK_M_S：正在等待获取共享锁。主要是查询，修改删除也都会有涉及到共享锁。
　　LCK_M_X：正在等待获取排它锁。在增删改中都会有涉及到排它锁。
　　LCK_M_SCH_S：正在等待获取架构共享锁。防止其它用户修改如表结构。
　　LCK_M_SCH_M：正在等待获取架构修改锁　如添加列或删除列这个时候使用的架构修改锁。

下面表格是统计分析

锁类型	锁等待次数	锁等待总时间（秒）	平均每次等待时间(毫秒)	最大等待时间
LCK_M_IX	26456	5846.871	221	47623
LCK_M_U	34725	425.081	12	6311
LCK_M_S	613	239.899	391	4938
LCK_M_X	4832	77.878	16	4684
LCK_M_SCH_S	397	77.832	196	6074
LCK_M_SCH_M	113	35.783	316	2268

　　注意： wait_time_ms 时间里，该时间表包括了signal_wait_time_ms信号等待时间，也就是说wait_time_ms不仅包括了申请锁需要的等待时间，还包括了线程Runnable 的信号等待。通过这个结论也能得出max_wait_time_ms 最大等待时间不仅仅只是锁申请需要的等待时间

3. 造成等待的现象和原因

现象：

　　(1) 用户并发越问越多，性能越来越差。应用程序运行很慢。

　　(2) 客户端经常收到错误 error 1222 已超过了锁请求超时时段。

　　(3) 客户端经常收到错误 error 1205 死锁。

　　(4) 某些特定的sql 不能及时返回应用端。

原因：

　　(1) 用户并发访问越多，阻塞就会越来越多。

　　(2) 没有合理使用索引，锁申请的数量多。

　　(3) 共享锁没有使用nolock，查询带来阻塞。好处是必免脏读。

　　(4) 处理的数据过大。比如：一次更新上千条，且并发多。

　　(5) 没有选择合适的事务隔离级别,复杂的事务处理等。

4. 优化锁的等待时间

　　在优化锁等待优化方面，有很多切入点像前几篇中有介绍 CPU和I/O的耗时排查和处理方案。我们也可以自己写sql来监听锁等待的sql 语句。能够知道哪个库，哪个表，哪条语句发生了阻塞等待，是谁阻塞了它，阻塞的时间。

　　从上面的平均每次等待时间(毫秒)，最大等待时间作为参考可以设置一个阀值。通过sys.sysprocesses 提供的信息来统计，关于sys.sysprocesses使用可参考 "sql server 性能调优从用户会话状态分析"。通过该视图监听一段时间内的阻塞信息。可以设置每10秒跑一次监听语句，把阻塞与被阻塞存储下来。

　　思想如下：

-- 例如 找出被阻塞会话ID 如时间上是2秒 以及谁阻塞了它的会话ID
SELECT spid,blocked #monitorlock FROM sys.sysprocesses 
where blocked>0 and    waittime>2000 

-- 通过while或游标来一行行获取临时表的 会话ID,阻塞ID，通过exec动态执行来获取sql语句文本 进行存储
exec('DBCC INPUTBUFFER('+@spid+')') 

exec('DBCC INPUTBUFFER('+@blocked+')')