?
本文檔使用 php中文網(wǎng)手冊(cè) 發(fā)布
VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ table [ (column [, ...] ) ] ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]
VACUUM回收已刪除行占據(jù)的存儲(chǔ)空間。在一般的PostgreSQL操作里, 那些已經(jīng)DELETE的行或者被UPDATE過后過時(shí)的行并沒有從它們所屬的表中物理刪除; 在完成VACUUM之前它們?nèi)匀淮嬖?。因此有必須周期地運(yùn)行VACUUM, 特別是在經(jīng)常更新的表上。
如果有參數(shù),VACUUM處理當(dāng)前用戶有權(quán)限清空的當(dāng)前數(shù)據(jù)庫(kù)中的每個(gè)表。
VACUUM ANALYZE先執(zhí)行一個(gè)VACUUM然后是給每個(gè)選定的表執(zhí)行 一個(gè)ANALYZE。對(duì)于日常維護(hù)腳本而言,這是一個(gè)很方便的組合。 參閱ANALYZE獲取更多有關(guān)其處理的細(xì)節(jié)。
簡(jiǎn)單的VACUUM(沒有FULL)只是簡(jiǎn)單地回收空間并且令其可以再次使用。 這種形式的命令可以和對(duì)表的普通讀寫并發(fā)操作,因?yàn)闆]有請(qǐng)求排他鎖。 然而,額外的空間不返回操作系統(tǒng);僅保持在相同表中可重用。VACUUM FULL 將表的全部?jī)?nèi)容重寫到一個(gè)沒有任何對(duì)于空間的新磁盤文件中,允許未使用的空間返回到操作系統(tǒng)中。 該格式在處理時(shí)更慢并要求每個(gè)表上一個(gè)獨(dú)占鎖。
當(dāng)選項(xiàng)列表被括號(hào)括起來時(shí),該選線可以任意順序來寫。沒有圓括號(hào),選項(xiàng)必須 按以上顯示的順序指定。PostgreSQL 9.0之前, 僅支持非括號(hào)的語法。期待的是所有新選項(xiàng)僅在括號(hào)語法中支持。
選擇"完全"清理,這樣可以恢復(fù)更多的空間,但是花的時(shí)間更多并且在表上施加了排它鎖。 該方法也需要額外的磁盤空間,因?yàn)樗鼘懥艘粋€(gè)表的新拷貝并且不釋放舊的拷貝,直到操作完成。 時(shí)才需要使用。
選擇激進(jìn)的行"凍結(jié)"。指定FREEZE相當(dāng)于執(zhí)行VACUUM時(shí)將 vacuum_freeze_min_age參數(shù)設(shè)為零。 FREEZE選項(xiàng)將在未來的版本中被取消,并且反對(duì)使用, 你應(yīng)當(dāng)使用設(shè)置正確的參數(shù)值的方法來達(dá)到目的。
為每個(gè)表打印一份詳細(xì)的清理工作報(bào)告
更新用于優(yōu)化器的統(tǒng)計(jì)信息,以決定執(zhí)行查詢的最有效方法。
要清理的表的名稱(可以有模式修飾)。缺省時(shí)是當(dāng)前數(shù)據(jù)庫(kù)中的所有表。
要分析的具體的字段名稱。缺省是所有字段。 若指定一個(gè)列的列表,就暗含ANALYZE。
如果指定了VERBOSE,那么VACUUM將發(fā)出處理過程中的信息, 以表明當(dāng)前正在處理那個(gè)表。 各種有關(guān)這些表的統(tǒng)計(jì)也會(huì)打印出來。
要清空一個(gè)表,一個(gè)人必須通常是表的所有者或是一個(gè)超級(jí)用戶。然而,數(shù)據(jù)庫(kù)所有者允許清空 其他數(shù)據(jù)庫(kù)中的所有表,除了共享目錄。(對(duì)共享目錄的限制意味著一個(gè)真正的數(shù)據(jù)庫(kù)范圍的 VACUUM僅能由超級(jí)用戶執(zhí)行。)VACUUM將跳過代用用戶沒有權(quán)限清空的 任何表。
VACUUM不能在事務(wù)塊內(nèi)執(zhí)行。
對(duì)于有GIN索引的表,VACUUM(以任何形式的) 也完成任何掛起索引插入,在主GIN索引結(jié)構(gòu)中,通過移動(dòng)掛起索引條目到合適的地方。 參閱Section 53.3.1獲取詳細(xì)信息。
建議生產(chǎn)數(shù)據(jù)庫(kù)經(jīng)常清理(至少每晚一次),以保證不斷地刪除失效的行。 尤其是在增刪了大量記錄之后,對(duì)受影響的表執(zhí)行VACUUM ANALYZE命令是一個(gè)很好的習(xí)慣。 這樣做將更新系統(tǒng)目錄為最近的更改,并且允許PostgreSQL 查詢優(yōu)化器在規(guī)劃用戶查詢時(shí)有更好的選擇。
不建議日常使用FULL選項(xiàng),但是可以在特殊情況下使用。一個(gè)例子就是在你刪除或更新一個(gè)表的大部分行之后,希望從物理上縮小該表以減少磁盤空間占用或允許快速表掃描。 VACUUM FULL通常要比單純的VACUUM收縮更多的表尺寸。
VACUUM導(dǎo)致I/O流量增加,可能會(huì)導(dǎo)致其它活動(dòng)會(huì)話的性能惡劣。因此, 有時(shí)候會(huì)建議使用基于開銷的vacuum延遲特性。參閱Section 18.4.3 獲取細(xì)節(jié)。
PostgreSQL包含一個(gè)"autovacuum"設(shè)施, 它可以自動(dòng)進(jìn)行日常的vacuum維護(hù)。關(guān)于手動(dòng)和自動(dòng)清理的更多細(xì)節(jié),參見 Section 23.1。
下面是一個(gè)在蛻變(regression)數(shù)據(jù)庫(kù)里某個(gè)表上執(zhí)行VACUUM的一個(gè)例子:
regression=# VACUUM (VERBOSE, ANALYZE) onek; INFO: vacuuming "public.onek" INFO: index "onek_unique1" now contains 1000 tuples in 14 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.18 sec. INFO: index "onek_unique2" now contains 1000 tuples in 16 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.07u sec elapsed 0.23 sec. INFO: index "onek_hundred" now contains 1000 tuples in 13 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.17 sec. INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.09u sec elapsed 0.59 sec. INFO: "onek": removed 3000 tuples in 108 pages DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec. INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages DETAIL: 0 dead tuples cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.07s/0.39u sec elapsed 1.56 sec. INFO: analyzing "public.onek" INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows VACUUM
SQL標(biāo)準(zhǔn)里沒有VACUUM語句。