1. 尽量不要在一个事务中实现过于复杂的查询或更新操作。原因很简单，越是复杂的数据库操作，占用数据库资源的时间越长，引发死锁的可能性越大。

2. 尽量不要在数据库事务中要求用户响应。原因同1，这也会导致事务长时间无法结束，浪费数据库资料。

3. 死锁是由于并发访问数据库资源造成的，减少死锁就应该限制应用系统的并发访问量。我们应该合理设置后台服务的线程数，将大量数据的操作分解，分步骤，分阶段的执行。也应该避免在用户量大的时候大规模的进行后台数据库操作，应该将大规模的数据库操作放在用户量最少的时候进行。

4. 尽可能以分区表或分区视图的方式拆分包含大量数据的表，将它们保存在不同的物量磁盘和文件组中。在访问数据时，可以分散访问保存在不同分区的数据，从而减少因为在大型表中放置锁而造成其它事务长时间等待的概率。

5. 尽量避免使用占用很长的复杂查询,在条件允许的情况下应该尽量使用分页查询或缩小结果集的方式。因为复杂查询会长时间占用数据库资源，增加发生死锁的概率。

6. 尽可能使用较低的隔离级别，如READ UNCOMMITTED，因为隔离级别低时，事务之间相互等待的情况会减少，这样每个事务都会尽可能快地完成数据库操作，然后释放其拥有的锁资源，这样就会降低出现锁等待或死锁的概率。当然，用户在设计数据库应用程序时，需要考虑如何解决事务中数据不一致的情况。

7. 应该注意统一访问表的顺序，尽量避免有的事务先查询表A然后更新表B，而有的事务先查询表B再更新表A的情况。

8. 如果一个事务中只进行读取数据的操作，则可以在该事务中使用快照(SNAPSHOT)隔离级别。因为在快照隔离级别中，数据库引擎不会阻塞其他事务对当前事务所占用资源的修改操作，当前事务会认为它所拥有的资源没有被修改过（实际上它所拥有的资源是一个快照）。这样就可以减少因为等待资源而产生死锁的情况。 

问题简单分析：

因为不同线程在事务中处理相同的数据时，在抢占数据库锁的过程中都拿到了这个表的锁，数据库会采取让一个执行而另一个放弃执行，会导致该错误的出现，即选作死锁牺牲品。

解决：

在update的语句中，加入 WITH (TABLOCKX)，对于这个的解释：

排它锁又称为写锁（(eXclusive lock,简记为X锁)），若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。它防止任何其它事务获取资源上的锁，直到在事务的末尾将资源上的原始锁释放为止。在更新操作（INSERT、UPDATE 或 DELETE）过程中始终应用排它锁。

使用如：UPDATE MT_EXP_SUB WITH (TABLOCKX) SET XXX = XXX WHERE ID = X;

加上这个排他锁之后，这个死锁的问题变解决了。

————————————————

版权声明：本文为CSDN博主「Forward233」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_35457078/article/details/85333993