PG数据库死亡元组过多导致查询慢优化方法

发布于 2021-09-22 07:49

集团云改数转战略背景下，随着越来越多的平台系统上云去O，很多系统数据库采用了PG（PostgresSQL）数据库。在使用PG数据库时，会发现有时候查询速度非常慢，以往很快就查询出来的，结果需要数十秒才行，检查发现没有锁，这时候一般都是表的死元组太多导致的。本文通过因为死亡元组过多导致数据库查询响应慢，从而引发IPTV3.0平台C1模板工单下发失败的案例，介绍PG数据库死亡元组清理及业务程序优化的方法。

一、PG数据库死亡元组介绍

PostgreSQL做delete操作时，数据集(也叫做元组、tuples)是没有立即从数据文件中移除的，仅仅是通过在行头部设置xmax做一个删除标记。update操作也是一样的，在postgresql中可以看作是先delete再insert。

这是PostgreSQL MVCC的基本思想之一，因为它允许在不同进程之间只进行最小的锁定就可以实现更大的并发性。这个MVCC实现的缺点是它会留下被标记删除的死亡元组（dead tuples），即使在所有事务完成之后依然存在。

如果不清理掉那些dead tuples（对任何事务都是不可见的）将会永远留在数据文件中，浪费磁盘空间，对于表来说，有过多的删除和更新，dead tuples很容易占绝大部分磁盘空间。而且dead tuples也会在索引中存在，更会加重磁盘空间的浪费。这是在PostgreSQL中常说的膨胀（bloat），需要处理的数据查询越多，查询的速度就越慢。

二、IPTV3.0平台EPG频繁更新引发查询慢问题案例

（一）问题描述

某天下午，号百与百视通等合作方反馈IPTV3.0平台C1接口出现工单失败。

（二）定位过程

1.检查接口机日志发现C1工单任务正常，任务已入库。

2.检查CP日志发现有SQL超时日志。