取消DELETE操作后Postgres表体积翻倍的原因及相关咨询

一、表体积膨胀的原因 #

PostgreSQL采用MVCC（多版本并发控制）机制，结合你中断DELETE操作的场景，膨胀原因主要有两点：

• DELETE的MVCC特性：执行DELETE时，PostgreSQL不会直接删除磁盘上的元组，而是给符合条件的元组标记死元组（设置元组的xmax为当前事务ID），同时更新对应索引的条目。这些死元组暂时不会被清理，仍占用磁盘空间。
• 未提交的事务状态：用Ctrl+C取消DELETE时，当前语句会被终止，但如果没有显式执行ROLLBACK，事务会处于未提交的打开状态。此时，PostgreSQL为了保证事务一致性，会保留这些死元组和索引死条目——既不能被autovacuum自动清理，也不会恢复为活元组。由于你的操作针对分区表，每个分区都会产生大量这类无效数据，最终导致所有分区体积翻倍。

二、VACUUM FULL能否解决膨胀问题 #

可以解决，但需要先处理未提交的事务：

1. 首先回滚未提交的事务：

   -- 先查看当前存在的事务
   SELECT pid, state, query FROM pg_stat_activity WHERE datname = '你的数据库名';
   -- 如果找到被中断的DELETE事务，执行回滚
   ROLLBACK;
   

2. 执行VACUUM FULL：
   它会重写整个表（包括所有分区和索引），将活元组压缩到连续的磁盘块中，彻底清理死元组和索引死条目，并将多余的磁盘空间释放给操作系统，能将表体积恢复到接近膨胀前的大小。

   注意：VACUUM FULL会对表加排他锁，执行期间表无法进行读写操作，建议在业务低峰期执行，且大表执行时间会较长。

   如果不想加排他锁，也可以先执行普通VACUUM清理死元组，将空间标记为可重用（但不会释放给操作系统），后续新数据会自动复用这些空间。

三、执行VACUUM是否会永久删除数据 #

分两种情况：

• 普通VACUUM：不会永久删除数据。它只会清理那些不再被任何事务快照需要的死元组，清理后的空间仅标记为可被新数据重用，旧数据仍留在磁盘上（直到被新数据覆盖）。只要你已经回滚了未提交的DELETE事务，它不会删除你需要保留的活数据。
• VACUUM FULL：会彻底删除磁盘上的死元组（因为它会重写表，只保留活元组），但同样，只要你先回滚了未提交的DELETE事务，它只会清理历史产生的无效死元组，不会影响你要保留的活数据。

补充：关于\s找不到查询历史的问题 #

\s仅显示当前psql会话的命令历史，如果你中断DELETE后退出过psql，或者中断操作导致历史记录未被写入，就无法看到这条语句。这是psql的历史记录机制限制，不影响数据库本身的事务状态处理。

内容的提问来源于stack exchange，提问作者Ozymandias