指数膨胀达57%,表胀仅为9%,autovacuum_vacuum_Scale_factor仅为10%。
更令人惊讶的是,甚至最关键的是有57%的膨胀。我的理解是,因为我的主键是自动递增的,而单列键只有在表死元组的10%之后,主键索引也应该有10%的死元组。
现在,当自动真空运行到死元组的10%时,它将清理死元组。死元组空间现在变得臃肿,这应该被新的更新重复使用,插入。但这在我的数据库中并没有发生,在这里,膨胀的规模在不断增加。
FYI:
指数膨胀:
current_database | schemaname | tblname | idxname | real_size | extra_size | extra_ratio | fillfactor | bloat_size | bloat_ratio
| is_na
------------------+------------+----------------------+----------------------------------------------------------+------------+------------+------------------+------------+------------+-------------------
+-------
stackdb | public | data_entity | data_entity_pkey | 2766848000 | 1704222720 | 61.5943745373797 | 90 | 1585192960 | 57.2923760177646 表膨胀:
current_database | schemaname | tblname | real_size | extra_size | extra_ratio | fillfactor | bloat_size | bloat_ratio | is_na
stackdb | public | data_entity | 10106732544 | 1007288320 | 9.96650812332014 | 100 | 1007288320 | 9.96650812332014 | f自动真空设置:
stackdb=> show autovacuum_vacuum_scale_factor;
autovacuum_vacuum_scale_factor
--------------------------------
0.1
(1 row)
stackdb=> show autovacuum_vacuum_threshold;
autovacuum_vacuum_threshold
-----------------------------
50
(1 row)注意:
自动真空打开
自动真空正在按规定的间隔成功运行。
postgreSQL正在运行10.6版。在12.x版本中也发现了同样的问题
发布于 2022-06-13 06:09:10
首先,57%的指数膨胀是完全健康的。别担心。
索引比表更臃肿,因为空空间不能像在表中那样自由地重用。该表(也称为al“堆”)没有预先确定的顺序:如果一个新行是作为INSERT或UPDATE的结果写入的,那么它最终会出现在具有足够空闲空间的第一页中,因此,如果VACUUM完成其工作,就很容易保持较低的膨胀。
B树索引是不同的:它们的条目有一定的顺序,因此数据库不能自由选择放置新行的位置。因此,您可能必须将其放入一个已经满的页面中,从而导致页面分割,而索引的其他部分则几乎是空的。
https://stackoverflow.com/questions/72596661
复制相似问题