pgsql数据表死锁解决办法

昨天在对一张表执行一条update语句的时候，没有修改成功，直接终止执行（这里的原因是还没有连接到数据库等了很久，不知道为啥dbever一会就得重连一次），就疯狂点击执行，执行了很多次这条语句导致了表被死锁了，所有人都无法访问这张表（还好在测试数据库。。。，正式上线了千万不要对正式数据库直接进行操作啊啊啊啊！！！！！吸取教训！！！）

我的解决办法是打开表的锁管理器，直接kill所有正在等待的pid，表恢复正常。

数据库中常见的死锁原因与解决方案有：

1. 事务之间对资源访问顺序的交替

出现原因： 
一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。

解决方法： 
这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源

2. 并发修改同一记录

出现原因：主要是由于没有一次性申请够权限的锁导致的。

用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁比较隐蔽，但在稍大点的项目中经常发生。 

解决方法：

a. 乐观锁，实现写-写并发

b. 悲观锁：使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

3. 索引不当导致的死锁

出现原因： 
如果在事务中执行了一条不满足条件的语句，执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，就很容易产生死锁和阻塞。类似的情况还有当表中的数据量非常庞大而索引建的过少或不合适的时候，使得经常发生全表扫描，最终应用系统会越来越慢，最终发生阻塞或死锁。

另外一种情况是由于二级索引的存在，上锁的顺序不同导致的

解决方法：

SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行分析，对于有全表扫描的SQL语句，建立相应的索引进行优化。