無(wú)VACUUM | VACUUM | VACUUM FULL | |
刪除大量數(shù)據(jù)之后 | 只是將刪除數(shù)據(jù)的狀態(tài)置為已刪除,該空間不能記錄被重新使用。 | 如果刪除的記錄位于表的末端,其所占用的空間將會(huì)被物理釋放并歸還操作系統(tǒng)。如果不是末端數(shù)據(jù),該命令會(huì)將指定表或索引中被刪除數(shù)據(jù)所占用空間重新置為可用狀態(tài),那么在今后有新數(shù)據(jù)插入時(shí),將優(yōu)先使用該空間,直到所有被重用的空間用完時(shí),再考慮使用新增的磁盤(pán)頁(yè)面。 | 不論被刪除的數(shù)據(jù)是否處于數(shù)據(jù)表的末端,這些數(shù)據(jù)所占用的空間都將被物理的釋放并歸還于操作系統(tǒng)。之后再有新數(shù)據(jù)插入時(shí),將分配新的磁盤(pán)頁(yè)面以供使用。 |
執(zhí)行效率 | 由于只是狀態(tài)置為操作,因此效率較高。 | 在當(dāng)前版本的PostgreSQL(v9.1)中,該命令會(huì)為指定的表或索引重新生成一個(gè)數(shù)據(jù)文件,并將原有文件中可用的數(shù)據(jù)導(dǎo)入到新文件中,之后再刪除原來(lái)的數(shù)據(jù)文件。因此在導(dǎo)入過(guò)程中,要求當(dāng)前磁盤(pán)有更多的空間可用于此操作。由此可見(jiàn),該命令的執(zhí)行效率相對(duì)較低。 | |
被刪除的數(shù)據(jù)所占用的物理空間是否被重新規(guī)劃給操作系統(tǒng)。 | 不會(huì) | 不會(huì) | 會(huì) |
在執(zhí)行VACUUM命令時(shí),是否可以并發(fā)執(zhí)行針對(duì)該表的其他操作。 | 由于該操作是共享鎖,因此可以與其他操作并行進(jìn)行。 | 由于該操作需要在指定的表上應(yīng)用排它鎖,因此在執(zhí)行該操作期間,任何基于該表的操作都將被掛起,知道該操作完成。 | |
推薦使用方式 | 在進(jìn)行數(shù)據(jù)清空是,可以使用truncate操作,因?yàn)樵摬僮鲗?huì)物理的清空數(shù)據(jù)表,并將其所占用的空間直接歸還于操作系統(tǒng)。 | 為了保證數(shù)據(jù)表的磁盤(pán)頁(yè)面數(shù)量能夠保持在一個(gè)相對(duì)穩(wěn)定值,可以定期執(zhí)行該操作,如每天或每周中數(shù)據(jù)操作相對(duì)較少的時(shí)段。 | 考慮到該操作的開(kāi)銷,以及對(duì)其他錯(cuò)誤的排斥,推薦的方式是,定期監(jiān)控?cái)?shù)據(jù)量變化較大的表,只有確認(rèn)其磁盤(pán)頁(yè)面占有量接近臨界值時(shí),才考慮執(zhí)行一次該操作。即便如此,也需要注意盡量選擇數(shù)據(jù)操作較少的時(shí)段來(lái)完成該操作。 |
執(zhí)行后其它操作的效率 | 對(duì)于查詢而言,由于存在大量的磁盤(pán)頁(yè)面碎片,因此效率會(huì)逐步降低。 | 相比于不執(zhí)行任何VACUUM操作,其效率更高,但是插入的效率會(huì)有所降低。 | 在執(zhí)行完該操作后,所有基于該表的操作效率都會(huì)得到極大的提升。 |
二、更新規(guī)劃器統(tǒng)計(jì):
PostgreSQL查詢規(guī)劃器在選擇最優(yōu)路徑時(shí),需要參照相關(guān)數(shù)據(jù)表的統(tǒng)計(jì)信息用以為查詢生成最合理的規(guī)劃。這些統(tǒng)計(jì)是通過(guò)ANALYZE命令獲得的,你可以直接調(diào)用該命令,或者把它當(dāng)做VACUUM命令里的一個(gè)可選步驟來(lái)調(diào)用,如VACUUM ANAYLYZE table_name,該命令將會(huì)先執(zhí)行VACUUM再執(zhí)行ANALYZE。與回收空間(VACUUM)一樣,對(duì)數(shù)據(jù)更新頻繁的表保持一定頻度的ANALYZE,從而使該表的統(tǒng)計(jì)信息始終處于相對(duì)較新的狀態(tài),這樣對(duì)于基于該表的查詢優(yōu)化將是極為有利的。然而對(duì)于更新并不頻繁的數(shù)據(jù)表,則不需要執(zhí)行該操作。
我們可以為特定的表,甚至是表中特定的字段運(yùn)行ANALYZE命令,這樣我們就可以根據(jù)實(shí)際情況,只對(duì)更新比較頻繁的部分信息執(zhí)行ANALYZE操作,這樣不僅可以節(jié)省統(tǒng)計(jì)信息所占用的空間,也可以提高本次ANALYZE操作的執(zhí)行效率。這里需要額外說(shuō)明的是,ANALYZE是一項(xiàng)相當(dāng)快的操作,即使是在數(shù)據(jù)量較大的表上也是如此,因?yàn)樗褂昧私y(tǒng)計(jì)學(xué)上的隨機(jī)采樣的方法進(jìn)行行采樣,而不是把每一行數(shù)據(jù)都讀取進(jìn)來(lái)并進(jìn)行分析。因此,可以考慮定期對(duì)整個(gè)數(shù)據(jù)庫(kù)執(zhí)行該命令。
事實(shí)上,我們甚至可以通過(guò)下面的命令來(lái)調(diào)整指定字段的抽樣率,如:
三、VACUUM和ANALYZE的示例:
四、定期重建索引:
在PostgreSQL中,為數(shù)據(jù)更新頻繁的數(shù)據(jù)表定期重建索引(REINDEX INDEX)是非常有必要的。對(duì)于B-Tree索引,只有那些已經(jīng)完全清空的索引頁(yè)才會(huì)得到重復(fù)使用,對(duì)于那些僅部分空間可用的索引頁(yè)將不會(huì)得到重用,如果一個(gè)頁(yè)面中大多數(shù)索引鍵值都被刪除,只留下很少的一部分,那么該頁(yè)將不會(huì)被釋放并重用。在這種極端的情況下,由于每個(gè)索引頁(yè)面的利用率極低,一旦數(shù)據(jù)量顯著增加,將會(huì)導(dǎo)致索引文件變得極為龐大,不僅降低了查詢效率,而且還存在整個(gè)磁盤(pán)空間被完全填滿的危險(xiǎn)。
對(duì)于重建后的索引還存在另外一個(gè)性能上的優(yōu)勢(shì),因?yàn)樵谛陆⒌乃饕?,邏輯上相互連接的頁(yè)面在物理上往往也是連在一起的,這樣可以提高磁盤(pán)頁(yè)面被連續(xù)讀取的幾率,從而提高整個(gè)操作的IO效率。見(jiàn)如下示例:
#1. 此時(shí)已經(jīng)在該表中插入了大約6萬(wàn)條數(shù)據(jù),下面的SQL語(yǔ)句將查詢?cè)撍饕加玫拇疟P(pán)空間。
1. 查看數(shù)據(jù)表所占用的磁盤(pán)頁(yè)面數(shù)量。
標(biāo)簽:錦州 珠海 來(lái)賓 株洲 晉城 烏海 衡陽(yáng) 蚌埠
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《PostgreSQL教程(十四):數(shù)據(jù)庫(kù)維護(hù)》,本文關(guān)鍵詞 PostgreSQL,教程,十四,數(shù)據(jù)庫(kù),;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。