案例主要是堆表索引等操作导致的，如下👇🏻之前的案例就表过不提了，感兴趣的老铁自己翻一下聊聊基础备份与FPI从一个案例聊聊FPI的危害那么什么场景会产生这样的记录？简单分析一下。2分析既然是

参数。3数据库层自身消耗数据库本身会做一些维护性的操作，比如vacuum/freeze等数据库可能有很多大表的年龄会先后到达2亿，数据库的autovacuum会开始对这些表依次进行vacuum

也会随之往前推进），假如一个库比较大并且很繁忙的话，备份就会耗时挺久，同事这个库就是1.5TB，其实也还好。另外值得注意的是，pg_basebackup

前言前些天，群里有一位童鞋提到这样一个案例："想请教一个问题，我的环境，我看后台只有一个delete在不停的执行，但是WAL日志涨的却非常快，2秒钟就切一个，这个表一共500多万条数据，这种情况正常么？"，不用说肯定不正常🤔，再加上许久之前同事也曾遇到过UUID导致的WAL写放大，那也赶此机会唠唠这个问题。根据过往经验，不同于WAL堆积无法回收，WAL生成速度暴涨一般是由于要么配置了过小的archive_timeout参数导致定时切换WAL的频率过高，要么就是WAL写放大导致实打实生成WAL速度过快，于是让这位童鞋使用pg_waldump看了一下，果然是FPI比例过高导致的WAL写放大。可以看到，最后的汇总处，FPI的比例竟然占据了

前言今天下午某位同事找到我说："有个SQL在数据库中执行1ms就能出结果，但是业务压测发起的SQL就会一直执行，查不出结果，进程也没有锁，CPU占用也很高"。让我们一起分析一下这个有趣的案例

前言这两天一直在纠结一个表膨胀的问题，分析的过程很艰辛，但是收获颇丰，请耐心阅读，相信各位能对vacuum和表膨胀理解得更加透彻。现象在2月19号，线上同事找过来说磁盘一直持续上涨，紧急扩容之后不一会又涨上去了。第一反应是不是WAL不断堆积？后来通过查看pg_stat_activity，发现某张表上vacuum跑了40多个小时，并且由于这个表在持续不断地执行update，表一直在膨胀中。不过奇怪的地方在于这个表据开发和运维反馈说之前一直都是正常的，就从18号开始不正常了，磁盘使用率持续上升。于是，登上去看了一下这台出问题的实例（由于涉及到生产安全，做了脱敏，下文都用test表代替生产表）。首先在操作系统层快速看一下，这个进程运行了2416分钟，大约40多个小时，并且还在跑，通过top

---------------------------------------------------------------------------------------------------

out到位于外部磁盘的swap分区上，当这部分内存之后再被使用时，又从swap分区换入。这个过程确实会触发相对慢速的磁盘I/O操作，但如果禁止了swap分区，当内存紧张时，系统就只能回收file