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+')')