SQLServerException：事务(进程 ID 79)与另一个进程被死锁在

具体报错信息如下：

根据查找资料的结果显示sqlserver的死锁，包括两种场景

场景1：

事务A: delele from table1 where id= 1; select * from table2;

事务B: delele from table2 where id= 1; select * from table1;

要理解这个场景，首先要了解两种锁的区别：X锁和S锁。简单的说，就是当试图删除、更新表时，我们会在该表上加一个X锁，这个X锁是排他锁，影响是除非表上的X锁被释放，不然其它人无法再加如何锁；而S锁是一个共享锁，它允许同一时间有多个共享锁存在，但是除了X锁以外。

假设场景1是并行执行的，事务1开始对table1加上了X锁，同时事务2也对table2加上了X锁。接下来它们又分别试图请求，在对方已经加上了X锁的表上加上S锁。从前面得知，X锁是排他锁，而事务的特性是，所有的锁资源都会在事务完成以后才释放。这时候事务间各自拥有对方请求的资源，又同时请求对方拥有的资源，并且要释放自身的资源，先要请求到对方的资源，就发生死锁了。

场景2：

事务A：delete from table1 where id =(1,..,n);
事务B：select c1,c2,c3 from table1 where id = (1,..,n)；
table1的索引如下，物理索引id，逻辑索引c1,c2。

据说这个场景的死锁比较普遍，但是很难理解，因为它们由始至终只操作一个表。要理解这个，还需从sqlserver中的bookmark search说起:如果select 语句中，查询的栏位不包含在逻辑索引中，比如c3，那么sqlserver将试图在使用物理索引id来查找c3的值。

现在再来看一下过程中发生的锁，select语句会在逻辑索引(c1,c2)上加上S锁，然后为了返回不在逻辑索引的栏位(c3)，它还需要在物理索引(id)上加上S锁；而更新呢？我们都知道，更新表时，我们需要对物理索引(id)加上排他锁以完成表的更新，并且随后还会被要求更新逻辑索引(c1,c2)。所以事务A先请求对id列的X锁，随后请求c1,c2列的X锁；而事务B会先请求c1,c2的S锁，接着请求id的S锁来返回c3的值。死锁就这样发生了。

幸亏这个场景发生的前提是频繁查询以及频繁更新表。

根据代码报错处的情况来看，更加符合第二种场景