置百丈玄冰而崩裂,掷须臾池水而漂摇。

怎样减少sqlserver中死锁的发生

数据库 强强
  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



发表评论:

验证码