最近遇到个很奇怪的问题，如标题所示。在文件系统上du -sh 表空间目录的大小是5T，在数据库里查所有的表+索引使用的存储是1.5T。
这多出来的3.5T不知道干什么的，在内外网找了半天没找到原因。基本都是表膨胀的问题。
最后还是同事说了一件事，原来在我来之前的二十天前该库的数据目录曾经占满过，因为一条sql，原因未知。后来业务清理了一些东西，数据库恢复以后就把表删了。但是表的元数据没有自动清理，似乎触发了什么bug。
现在这个表有三千多个元数据文件。
ps：relpages*8是因为这个字段是页数量，pg中一页是8K。
ps:这样统计有问题，如果统计信息没更新的话，可能不准。
有需要可以用这个命令看 可能有点慢。
SELECT pg_size_pretty(pg_relation_size(pg_class.oid)), pg_class.relname, pg_namespace.nspname,
CASE pg_class.relkind WHEN 'r' THEN 'table' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN 'v' THEN 'view' WHEN 't' THEN 'TOAST' ELSE pg_class.relkind::text END
FROM pg_class
LEFT OUTER JOIN pg_namespace ON (pg_namespace.oid = pg_class.relnamespace)
ORDER BY pg_relation_size(pg_class.oid) DESC;
relpages是有多少个数据页。
现在考虑的方案有三个
1.全库执行vacuum full，不确定有没有用。
2.将全库pg_dump备份，再将所有1524526文件删除，有一定的风险。
3.全库pg_dump备库，再重建库恢复。代价大，麻烦。
这种情况是“孤儿文件”，具体原因看这个链接https://www.cnblogs.com/abclife/p/13948101.html
怎么查出来看这个链接https://mp.weixin.qq.com/s/N-NCa9pVoQde5EcuFqiP_g
本次现场环境用的是第二个方法，没有出现问题。但还是提醒一下，做好备份。数据无价。
