PostgreSQL：由於索引膨脹導致性能下降
我在 CentOS 4.4 系統上執行 PgSQL 8.1（不幸的是無法升級）。
在 PgSQL 守護程序之上執行了一個 Java 應用程序，我們必須每 2 個月左右重新索引一次數據庫。同樣重要的是：數據庫沒有增長。
看起來膨脹現在比以前更快，而且這往往會增加。
我的配置在這裡可用，autovacuum 守護程序已啟用並經常執行：pastebin.com/RytNj7dK
您還可以找到此查詢的輸出 wiki.postgresql.org/wiki/Show_database_bloat
執行 reindex 3 小時後：http
://pastebin.com/raw.php?i=75fybKyd 執行 reindex 72 小時後： http://pastebin.com/raw.php?i= 89VKd7PC有誰知道我應該調整什麼來擺脫日益增長的臃腫？
謝謝你的幫助
PS：由於反垃圾郵件預防系統，我不得不為我的兩個第一個連結刪除前 2 個 http:// 前綴。
不幸的是，如果你有一個活動的數據庫（一個有很多插入/更新/刪除的數據庫），你會遇到索引膨脹——這只是數據庫生命中的一個事實。您能做的最好的事情就是希望將膨脹減慢到您的重新索引間隔合理的程度。
在這方面我能給你的最好建議是升級到更新版本的 Postgres（8.3 或更高版本）：這是 Postgres 引入僅堆元組支持的時候。
現在在您的（8.1）系統上，就索引而言，對行的***任何更新都相當於刪除/插入，因此索引膨脹。***8.3 及更高版本除非必須，否則不要觸摸索引（“如果該行仍然適合它所在的頁面”）。
升級到支持 HOT 的 Postgres 版本後，如果您
UPDATE的 s 正在接觸索引列，或者您UPDATE的 s 大幅增加行的大小以使其必須移動到新頁面，您可能仍然會遇到索引膨脹，但是這些如果您的索引策略是健全的並且您的行的大小相對靜態，那麼這種情況應該相對不常見，因此索引膨脹問題應該不成問題。處理索引膨脹的一些額外的一般策略：
- 主鍵索引
你在這裡很不走運 - 你需要
REINDEX並獲得表鎖。 2. 其他索引
- 選項 1：
DROP和重新CREATE非關鍵索引這具有不鎖定表的優點，但缺點是在重建時刪除索引。
- **選項 2：**關鍵索引的索引洗牌
而不是上面的刪除/創建過程，首先創建一個新索引，然後在完成後刪除舊索引並重命名新索引以取代它。
這具有不鎖定表的優點，並且具有使原始索引正常工作（儘管臃腫）的優點。主要缺點是您必須重命名索引以保持命名約定的合理性——這是一個額外的手動步驟。