一、死锁的表现
1、错误信息是:事务(进程 ID)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。
2、错误信息是:事务(进程 ID )与另一个进程被死锁在 锁 | 通信缓冲区 资源上，并且已被选作死锁牺牲品。请重新运行该事务。

二、死锁的原因
1、由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状态，从而造成其对资源需求的死锁。

2、数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11 中，最小锁为 2K一页的加锁方法，而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)，被访问的频率高，就容易在该页上产生死锁。

表现一：
一个用户 A 访问表 A(锁住了表 A)，然后又访问表 B。另一个用户 B 访问表 B(锁住了表 B)，
然后企图访问表 A。这时用户 A 由于用户 B 已经锁住表 B，它必须等待用户 B 释放表 B，
才能继续，同样用户 B 要等用户 A 释放表 A 才能继续操作，这样就造成了死锁。
解决方法：
这种死锁是由于程序的 BUG 产生的，需调整程序对数据库层的实现逻辑。仔细分析程序的逻辑：
（1）尽量避免同时锁定两个资源。
（2）必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。

表现二：
用户 A 读一条纪录，然后修改该条纪录，同时用户 B 也修改该条纪录。这里用户 A 的事务里锁的性质由共享锁企图上升到独占锁 (for update)，而用户 B 里的独占锁由于 A 有共享锁存在所以必须等 A 释放掉共享锁，而 A 由于 B 的独占锁而无法上升的独占锁也就不可能释
放共享锁，于是出现了死锁。这种死锁比较隐蔽，但其实在稍大点的项目中经常发生。
解决方法:
让用户 A 的事务（即先读后写类型的操作)，在 select 时就是用 update lock。
语法如下：select * from table1 with(updlock) where ….