阻塞原因之一是不同的Session在访问同一张表的时候因为不兼容锁的原因造成的，
　　当前执行的SQL语句是否被阻塞（或者死锁），不仅跟当前表上的已有的锁有关，也会跟当前执行的SQL语句的执行方式有关
　　简单来说，对于表的访问方式，SQL语句的执行无非是表扫描，索引扫描，（聚集索引或者非聚集索引）索引查找等等
　　如果SQL语句的执行方式不当或者没有合理的索引，会造成没必要的阻塞，如果逻辑控制不当，甚至造成更严重的问题，造成数据逻辑的错误

建个测试表，下面测试演示一下

create table testIndexAndLock(    id int identity(1,1),    col2 varchar(50))GOinsert 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的数据行，可以发现这个查询可以顺利完成

　　这个就是通过索引改变查询的执行计划，避免全表扫描的时候遇到任何一行数据上有排它锁造成阻塞的情况。
　　这里说的索引，并不仅仅是为了提高效率，更重要的是改变了查询的执行方式，避免遇到表上有排他性锁的锁在成阻塞的情况。

索引的作用不仅仅是提高查询效率，更重要的是避免全表扫描的过程中遇到排它锁被阻塞的情况，对减少阻塞有一定的帮助作用。

Sql Server 优化----SQL语句的执行方式与锁以及阻塞的关系