我正在参与「启航方案」

衔接列表办理

我们呢或许时不时地会遇到一些想要中止数据库衔接的状况，比方履行了写得很糟糕的SQL句子，把系统资源耗光。产生这个呢，我们当然是希望能结束这些操作或者彻底爽性中止这个衔接。

想要中止正在履行的句子并杀掉衔接，就要运用以下过程：

SELECT * FROM pg_stat_activity;

pg_stat_activity这个视图包括每个衔接上在最近一次履行的句子，运用的用户名（usrname字段），地点的databases名（datname字段）以及句子开端履行的时刻。通过查询该视图能够找到需求中止的会话所对应的进程ID。

中止衔接（假设对应的进程号为1234）上的活动查询
```
SELECT pg_cancel_backend(1234);
```
该操作不会中止衔接本身
中止该衔接
```
SELECT pg_terminate_backend(1234);
```
有时候会需求中止这个衔接，特别是履行数据库恢复之前。假如仅仅是中止了正在履行的句子而没有彻底杀掉衔接，客户端是能够立即重新履行刚刚被中止掉的句子的，这又会导致系统陷入之前的状况。为了避免此种状况的产生，能够选用直接中止衔接的方式。假如未中止某个衔接上正在履行的句子就直接去中止该衔接，那么这些句子也会被中止掉。

由于Postgresql支撑在select查询句子中调用函数。因而，尽管pg_terminate_backend和SELECT pg_cancel_backend一次仅能处理一个衔接，但你能够通过select句子中调用函数的方式完成一次处理多个衔接。

比方说希望一次性中止某个用户的一切衔接，那么能够履行以下句子。

SELECT pg_terminate_backend(pid) FROM pg_stat_activity
where  usename = 'some_role';

Postgresql有一些句子参数能够用来操控句子的运转状况，一旦句子运转期间的某些状况值超过了这些运转参数所限制的范围，该句子会被系统主动杀掉。这些参数能够在服务实例级，databases级，用户级，会话级和函数级设置。参数值设为0代表禁用。

deadlock_timeout

该参数表明阿紫进行死锁检测之前需求等候多久。默许是1000毫秒。假如你的业务系统中有大量更新操作，那么主张增大该值以削减死锁检测的次数。

当然，与其依靠这个参数就处理死锁，其实是更主张在UPDATE句子中加NOWAIT子句来避免死锁。

例如：
```
SELECT FOR UPDATE NOWAIT 。。。
```
statement_timeout

该参数能够操控一个句子能够履行的最长时刻，超出限制的时刻后该句子会被主动中止。该参数默许值为0，即无限制。

可是为了避免误杀，最好不要把这个参数设置为大局级别，仅在要操控的函数的界说中针对该函数本身设置一下既可。
lock_timeout

该参数操控锁等候的最长时刻，超出限制时刻后等候锁的句子就会被主动中止。对于履行数据更新的句子来说，该参数有较大的价值，由于每次更新数据之前都必须先获取待修正的记载上的排他锁，所以更新句子之间是最容易产生锁等候的。lock_timeout的值应该设得比statement_timeout小，否则就是总会句子先超时，这样lock_timeout就毫无意义了。

死锁检测是很昂贵的操作，因而系统不会每次产生锁等候都去做死锁检测

idle_in_transaction_session_timeout

该参数表明一个业务能够处于idle状况的最长时刻，超过限制的时刻后该业务会被主动回滚。该参数的默许值为0，表明业务能够永久处于idle状况。该参数是9.6版本引进的。能够起到两个作用：避免一个闲暇业务占着记载锁一致不开释然后堵塞其他业务继续运转，还能够避免一个数据库衔接被一个闲暇业务永久占用。

查看被堵塞句子的状况：

在pg的9.6版本中，pg_stat_activity视图中的waiting字段变为了wait_event_type和wait_event的字段，其间记载了当时会话上的句子在等候什么资源。

PostgreSQL数据库–杀死那些糟糕的SQL语句