阻塞原因之一是不同的Session在访问同一张表的时候因为不兼容锁的原因造成的，
当前执行的SQL语句是否被阻塞（或者死锁），不仅跟当前表上的已有的锁有关，也会跟当前执行的SQL语句的执行方式有关
简单来说，对于表的访问方式，SQL语句的执行无非是表扫描，索引扫描，（聚集索引或者非聚集索引）索引查找等等
如果SQL语句的执行方式不当或者没有合理的索引，会造成没必要的阻塞，如果逻辑控制不当，甚至造成更严重的问题，造成数据逻辑的错误
建个测试表，下面测试演示一下
create table testIndexAndLock
(
id int identity(1,1),
col2 varchar(50)
)
GO
insert into testIndexAndLock values (NEWID())
GO 100000
很常见的业务就是，当前Session中开启了事物，执行更新或者删除某一行数据，然后再进行一系列其他的操作，当前事物提交之前，该排它锁一致保持，直到事物提交
比如下面截图：
第一个Session中利用事物和排他性操作锁定一行数据，，进行业务逻辑处理，按道理来说：目的仅仅是锁定当前行的数据（id = 6666），进行排他性操作，并没有锁定其的数据行
然后再第二个Session中，查询其他的无关的Id，按道理，上面一个Session只是锁定了id = 6666的行，怎么当前Session查询Id = 7777的行的时候会被阻塞呢？
这里就是上面说的对当前表的访问方式了，因为当前查询的表上没有任何索引，在查询id = 7777的时候，虽然id = 7777的行上没有任何锁，为什么查询还是被阻塞？
这里在执行查询id = 7777的时候，用的是全表扫描的方式执行的，此时遇到Id = 6666的这行数据的时候，因为这行数据上有排它锁，当前Session被阻塞
可以简单理解为当前Session会逐行扫描表中的数据行，在扫描的过程中，不管是表也好，数据行也好，如果遇到兼容的锁，可以正常访问，
如果遇到不兼容的锁，比如这里的查询是共享锁（s锁），遇到第一个Session中的id = 6666的这行数据的时候，发现上面是排它锁，
此时，当前Session要对该行加的锁（共享锁）与该行上的排它锁（x锁）不兼容，就只能等待，知道id = 6666这行数据上的排它锁释放或者变化与当前请求的共享锁兼容的锁，才能执行
如果id = 6666上面的排它锁一直没有释放或者变化为兼容共享锁的锁类型，当前Session就一直等待
表现为当前Session被阻塞
这种问题解决办法也很简单，类似现象如果要不被阻塞，要么等到第一个Session的排它锁释放，要么就换一种查询的方式
尝试在表的Id列上建立一个索引，当然聚集索引也可以，目的是防止查询的时候以全表扫描的方式进行
在第二个Session中执行上面的查询，查询Id = 7777的数据行，可以发现这个查询可以顺利完成
这个就是通过索引改变查询的执行计划，避免全表扫描的时候遇到任何一行数据上有排它锁造成阻塞的情况。
这里说的索引，并不仅仅是为了提高效率，更重要的是改变了查询的执行方式，避免遇到表上有排他性锁的锁在成阻塞的情况。
索引的作用不仅仅是提高查询效率，更重要的是避免全表扫描的过程中遇到排它锁被阻塞的情况，对减少阻塞有一定的帮助作用。