PostgreSQL出现死锁怎么办？

什么是出现数据库死锁

在操作系统领域当中，死锁指的死锁是两个或者两个以上的进程在运行的过程中，因为争夺共同的出现访问资源而相互等待阻塞，最终导致进程继无法续执行的死锁一种阻塞现象。那么在数据库领域当中死锁又是出现怎样的表现形式呢?数据库死锁又会带来怎样的问题呢?

在理解数据库死锁之前，我们先来明确下数据库的死锁锁到底是什么?有过Java编程经验的同学都知道，Java中的出现锁是为了解决共享数据的并发访问安全问题，防止并发访问导致的死锁共享数据出现错乱。那么在数据库领域，出现数据库中的死锁锁又是来干什么的呢?实际上在数据库中所也是解决并发问题。假如在同一时刻，出现可能存在多个事务对同一张表的死锁同一个字段进行数字的服务器托管加减操作，如果没有任何的出现控制措施也同样会导致各种各样的数据一致性问题。因此数据库的死锁锁实际上也是为了保证数据一致性的一种手段，对可能存在的出现并发操作进行控制。

下面以一个例子来进行说明，假设有这样两个事务，事务A中包含如下语句：

UPDATE user SET name = 小慕 id = 1

UPDATE product SET price = price * 10 WHERE id = 2

事务B中包含如下语句：

UPDATE product SET price = price * 100 WHERE id = 2

UPDATE user SET name = 小枫 WHERE id = 1

如果这两个事务并发执行，那么他们可能存在如下的执行情况，当事务A执行的时候，首先运行了查询语句：

UPDATE user SET name = 小慕 id = 1

相当于事务A给id为1的数据行加上了排他锁，但是事务并没有执行完也就是说此时事务A持有user表的id为1的排他锁，排他锁的特性就是此时其他事务不能对数据进行删除和修改，因此只有等待事务结束释放锁之后才能重新获取。

此时事务B执行更新语句获取了product表id为2的排他锁，接着事务B开始执行user表的update语句，需要获取user表的网站模板id为1的排他锁。但是此时事务A并未提交，因此事务A持有表user的id为1的排他锁，事务B只有乖乖阻塞等待事务A释放锁。而此时事务A执行update语句，需要获取product的id为2的排他锁，但是此时事务B持有该排他锁，因此也需要等待事务B锁释放。

UPDATE product SET price = price * 10 WHERE id = 2

事务A在等待事务B结束释放锁，而事务B又在等待事务A释放锁，最终陷入了互相等待的情况也就是所谓的死锁。

那么数据库出现死锁又会导致什么问题呢?数据库死锁会导致严重的性能问题，可能平台因为数据库死锁而导致运行缓慢，严重影响用户正常使用业务，因此如果出现数据库死锁情况需要及时发现以及解决。

定位死锁

//先确定数据库有没有死锁情况发生

select * from pg_stat_activity where datname = product_db;

//查询可能锁了的表的oid

select oid from pg_class where relname=product;

//查询对应的pid

select pid from pg_locks where relation=oid //上面查询出来的oid

//取消或者终止对应的进程破坏死锁条件

select pg_cancel_backend(pid);

select pg_terminate_backend(pid)；

死锁可能原因及解决办法

以上分析了PostgreSQL出现死锁后如何定位分析，那么接下来就需要总结分析分析下PostgreSQL出现死锁情况的b2b信息网原因以及一般的应对解决办法。

1、索引使用不当导致的死锁问题

索引使用存在问题的话会导致死锁问题，假设在一个数据查询的事务当中，进行数据检索的时候没办法按照SQL中的where条件进行查询，因此导致了全表扫描，那么此时数据库表的行级锁会上升为表级锁。如果此时有多个未能按照where条件进行数据查询的事务存在，那么就容易导致数据库死锁问题。也就是说在数据库表数据量比较大的时候，对应进行数据查询的表没有建立索引或者说索引创建的不合理导致无法通过索引进行数据查询，只能通过全表索引，这样的场景下就容易产生死锁。

如何避免：

在进行数据查询的时候，对应的SQL语句不宜太过复杂，也就是说尽量避免多张表的关联查询。

2、不同事务之间的访问顺序问题

当用户A 访问数据库表A时，此时对表A加了共享锁，然后又访问数据库表B。而此时另一个用户B 访问表B，对表B加了共享锁，然后试图访问表A。但是用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，也就是说互相等待对方释放资源，从而导致了死锁的发生。

如何避免：

这种情况在实际项目中遇到的可能比较多，主要还是需要通过控制代码的执行逻辑，避免多表操作时同时锁住多个资源。

避免死锁的建议

(1)如果平台中存在大事务，尽量将其拆分为小事务。因为大事务一般操作的数据库表或者数据都比较多，因此造成死锁或者阻塞的概率就会相对较大。

(2)为数据库表设计合理的索引，尽量避免数据查询时索引未覆盖或者索引失效的情况，因为全表扫描会会导致给表中的数据行上锁，大大增加了数据库产生死锁的概率。

(3)如果业务允许，我们可以尝试将隔离级别调低，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。

(4)在我们自己的代码中，尽量以一致的顺序获取对象上的锁，避免事务中SQL交互执行，从而降低死锁发生的概率。

很赞哦!（6533）