?
Dieses Dokument verwendet PHP-Handbuch für chinesische Websites Freigeben
REINDEX { INDEX | TABLE | DATABASE | SYSTEM } name [ FORCE ]
REINDEX使用表中的數(shù)據(jù)重建索引。使用REINDEX有兩個(gè)主要原因:
索引崩潰,并且不再包含有效的數(shù)據(jù)。盡管理論上這是不可能發(fā)生的, 但實(shí)際上索引會(huì)因?yàn)檐浖』蛘哂布栴}而崩潰。 REINDEX提供了一個(gè)恢復(fù)方法。
索引變得"臃腫",包含大量的空頁或接近空頁。這個(gè)問題在某些罕見訪問模式時(shí)會(huì)發(fā)生在B-tree索引上。 REINDEX通過寫一個(gè)不帶無用索引頁的新索引提供了縮小索引空間消耗的途徑。參閱Section 23.2獲取更多信息。
為索引更改了存儲(chǔ)參數(shù)(例如填充因子),并且希望這個(gè)更改完全生效。
使用CONCURRENTLY選項(xiàng)創(chuàng)建索引失敗,留下了一個(gè)"非法"索引。這樣的索引毫無用處, 但是可以通過REINDEX重建新索引來覆蓋。注意,REINDEX不能并發(fā)創(chuàng)建。 要在生產(chǎn)環(huán)境中重建索引并且盡可能減小對(duì)尖峰負(fù)載的影響,可以先刪除舊索引, 然后使用CREATE INDEX CONCURRENTLY命令重建新索引。
重新建立指定的索引。
重新建立指定表的所有索引。如果表有從屬的"TOAST"表,那么這個(gè)表也會(huì)重新索引。
重建當(dāng)前數(shù)據(jù)庫里的所有索引。共享系統(tǒng)表上的索引也要處理。 REINDEX的形式不能在一個(gè)事務(wù)鎖內(nèi)被執(zhí)行。
在當(dāng)前數(shù)據(jù)庫上重建所有系統(tǒng)表上的索引。 共享系統(tǒng)表上的索引包括在內(nèi)。用戶表上的索引不處理。 這種形式的REINDEX不能在事務(wù)塊中執(zhí)行。
需要重建索引的索引、表、數(shù)據(jù)庫的名稱。表和索引名可以有模式修飾。 目前,REINDEX DATABASE和REINDEX SYSTEM只能重建當(dāng)前 數(shù)據(jù)庫的索引,因此其參數(shù)必須匹配當(dāng)前數(shù)據(jù)庫的名字。
這是一個(gè)廢棄的選項(xiàng),如果聲明,會(huì)被忽略。
如果你懷疑一個(gè)用戶表上的索引崩潰了, 你可以簡單地使用REINDEX INDEX重建該索引,或者使用 REINDEX TABLE重建該表上的所有索引。
如果你從一個(gè)崩潰的系統(tǒng)表索引上恢復(fù),事情會(huì)更棘手一些。這種情況下, 系統(tǒng)必須不能使用任何有疑問的索引。實(shí)際上,在這種情況下,你可能發(fā)現(xiàn)服務(wù)器進(jìn)程在啟動(dòng) 之后馬上就崩潰了,因?yàn)橐蕾囉诒罎⒘说乃饕?。要想安全恢?fù),服務(wù)器必須帶著-P選項(xiàng)啟動(dòng), 它禁止服務(wù)器在查找系統(tǒng)表的時(shí)候使用索引。
達(dá)到這個(gè)目的的一個(gè)方法是停止服務(wù)器然后帶著-P命令行選項(xiàng)啟動(dòng)一個(gè)獨(dú)立的 PostgreSQL服務(wù)器。 然后,根據(jù)你希望恢復(fù)的程度,發(fā)出REINDEX DATABASE,REINDEX SYSTEM, REINDEX TABLE, REINDEX INDEX 命令。如果還有懷疑,使用REINDEX SYSTEM選擇重新構(gòu)造數(shù)據(jù)庫中全部的系統(tǒng)索引。 然后退出獨(dú)立服務(wù)器會(huì)話并且重啟普通的服務(wù)器。參閱postgres手冊(cè)頁獲取有關(guān) 如何與獨(dú)立服務(wù)器交互的信息。
另外,一個(gè)普通的會(huì)話可以在其命令行選項(xiàng)里使用-P選項(xiàng)啟動(dòng)。 這么做的方法因不同的客戶端而異,但是在所有基于libpq的客戶端上, 都可以通過在啟動(dòng)客戶端之前設(shè)置PGOPTIONS環(huán)境變量為-P來實(shí)現(xiàn)。 請(qǐng)注意盡管這個(gè)方法并不要求鎖住其它客戶端,但是禁止其它客戶端連接受損的數(shù)據(jù)庫,直到完成修補(bǔ)是一個(gè)明智的選擇。
REINDEX類似于刪除并重建索引,表現(xiàn)在它們都是從零開始重建。 不過,從鎖的角度考慮,兩者是有區(qū)別的。REINDEX鎖住對(duì)表的寫操作, 但是不鎖讀操作。并且它還在被處理的特定索引上保持一個(gè)排他鎖, 這樣它將阻止試圖使用該索引的讀操作。相比之下,DROP INDEX在父表上短暫的保持一個(gè)排他鎖, 同時(shí)鎖住讀和寫。隨后的CREATE INDEX鎖住寫操作但是不會(huì)鎖住讀操作;因?yàn)樗饕€不存在 ,所以不會(huì)有試圖使用它的讀操作,意味著操作中不會(huì)有阻塞,只不過讀操作會(huì)被迫只能使用順序掃描。 另外一個(gè)重要的環(huán)節(jié)是刪除/重建的方法讓所有使用索引的緩沖的查詢規(guī)劃都失效,而REINDEX不會(huì)。
對(duì)一個(gè)索引或者表進(jìn)行重建索引,要求你是該索引或者表的所有者。對(duì)一個(gè)數(shù)據(jù)庫重 建索引要求你是該數(shù)據(jù)庫的所有者(注意,可以重建其它用戶擁有的索引)。當(dāng)然,超級(jí) 用戶總是可以重建所有索引。
PostgreSQL 8.1之前,REINDEX DATABASE只處理系統(tǒng)索引,而不是人們從名字猜測(cè)的那樣, 處理所有索引。這個(gè)行為現(xiàn)在已經(jīng)改變了,以減少意外的因素。舊的行為可以通過REINDEX SYSTEM獲得。
PostgreSQL7.4之前,REINDEX TABLE并不自動(dòng)處理TOAST表, 因此這些表必須用獨(dú)立的命令進(jìn)行處理。這么做仍然可以,但是已經(jīng)多余了。
重建一個(gè)單獨(dú)的索引:
REINDEX INDEX my_index;
重建表my_table上的所有索引:
REINDEX TABLE my_table;
重建一個(gè)數(shù)據(jù)庫上的所有系統(tǒng)索引,不管系統(tǒng)索引是否仍然有效:
$ export PGOPTIONS="-P" $ psql broken_db ... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q
SQL標(biāo)準(zhǔn)里沒有REINDEX命令。