作者 | Haki Benita
編譯 | 伍杏玲
出品 | AI科技大本營（ID：rgznai100）
【導語】春節將至，俗話說“臘月二十四，撣塵掃房子”，很多人會在臘月二十四給家裏做大掃除迎新春。
近年來數據呈爆發式增長，你是否和本文作者一樣，常常收到數據庫空間的告警呢？那來給數據庫做一場“大掃除”試試看？
作者講述親身經歷，在沒有刪除單個索引或刪除任何數據下，最終釋放了超過70GB的未優化和未利用的空間，還意外釋放 20GB 未使用索引空間。
咱們一起看看他是如何做到的：
每隔幾個月，我都會收到數據庫即將用完空間的報警。一般我看到報警後，就再增加一些存儲空間，不會多投入精力在那。
但這次我們想給數據庫來一次“大掃除”，效果驚人：在沒有刪除單個索引或刪除任何數據下，最終釋放了超過 70GB 的未優化和未利用的空間！還有清除了額外的 20GB 未使用的索引值！
這是其中一個數據庫的釋放存儲的圖：
刪除未被使用過的索引
未被使用的索引是一把“雙刃劍”。我們創建它的本意是爲了讓搜索更快，但它也佔用一定的空間，將會影響新增和更新的速度。所以沒被使用的索引是我們在清除存儲首先要檢查的。
查找未使用的索引：
SELECT
relname,
indexrelname,
idx_scan,
idx_tup_read,
idx_tup_fetch,
pg_size_pretty(pg_relation_size(indexrelname::regclass)) as size
FROM
pg_stat_all_indexes
WHERE
schemaname = 'public'
AND indexrelname NOT LIKE 'pg_toast_%'
AND idx_scan = 0
AND idx_tup_read = 0
AND idx_tup_fetch = 0
ORDER BY
size DESC;
這個查詢語句是查找自上次重置統計信息以來，未被掃描或獲取的索引。
有一些索引看起來沒有被使用，但實際上已被使用了：
可參考：https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW
用那些有一定的時間沒更新的表裏唯一或主鍵約束的索引。這些索引看起來好像沒有被使用過，但我們也不能隨意處置它們。
在實際找這些可刪除的未使用的索引時，剛開始很耗時耗力，需要很多思考和決策的。
在這過程中，我發現在檢查完列表後，重置統計信息計數器是個好方法。PostgreSQL 提供了一些功能來重置不同級別的統計信息。當我發現“疑似”未使用的索引時，或者添加新索引代替舊索引時，通常會重置表的計數器並等待一段時間：
-- Find table oid by name
SELECT oid FROM pg_class c WHERE relname = 'table_name';
-- Reset counts for all indexes of table
SELECT pg_stat_reset_single_table_counters(14662536);
我們每隔一段時間執行一次上述操作來看看有沒有要刪除的未使用索引。
索引和表格
當我們在更新表中的行時，通常 PostgreSQL 將元組標記爲無效，並在下一個可用空間中添加更新的元組，此過程將創建“bloat”，可能會導致表消耗超出實際所需的空間，因此我們需要清除索引bloat。
那我們需要重建索引，PostgreSQL提供了一種使用REINDEX命令就地重建現有索引的方法，無需自己刪除和創建索引（https://www.postgresql.org/docs/current/sql-reindex.html）：
REINDEX INDEX index_name;
同時重建索引：先前的方法將在表上獲得一個鎖，防止在操作進行時更改，這似乎不大好使，如果在不鎖定索引下重建索引的話，可以同時重建索引：
REINDEX INDEX CONCURRENTLY index_name;
使用 REINDEX CONCURRENTLY 時，PostgreSQL將創建一個名稱後綴爲“_ccnew”的新索引，並同步對該表更改。重建完成後，它將用新索引切換舊索引，並刪除舊索引。
如果由於某種原因你不得不在中間停止重建，也不會刪除新索引，它將處於無效狀態並佔用空間。爲了識別在這些無效索引REINDEX，可使用以下查詢：
SELECT
c.relname as index_name,
pg_size_pretty(pg_relation_size(c.oid))
FROM
pg_index i
JOIN pg_class c ON i.indexrelid = c.oid
WHERE
-- New index built using REINDEX CONCURRENTLY
c.relname LIKE '%_ccnew'
-- In INVALID state
AND NOT indisvalid
LIMIT 10;
一旦重建過程沒有其他執行，應該可以安全刪除所有剩餘的無效索引。
激活 B 樹索引 Deduplication
PostgreSQL 13引入了一種在B樹索引存儲重複值的新方法，稱爲“B樹 Deduplication”（重複數據刪除）。
對於每個索引值，B樹索引將在其葉中同時保留值和指向行的指針（TID）。索引值越大，索引越大。PostgreSQL 12 當索引包含許多重複值時，這些重複值將存儲在索引葉中。如此一來，將佔用很多空間。
從PostgreSQL 13開始，將 B樹Deduplication後，重複值僅存儲一次，這對具有許多重複值的索引的大小產生影響。
在PostgreSQL 13中，索引 Deduplication 默認情況下處於啓用狀態：
-- Activating de-deduplication for a B-Tree index, this is the default:
CREATE INDEX index_name ON table_name(column_name) WITH (deduplicate_items = ON)
如果要從PostgreSQL 13 之前的版本遷移的話，需要使用 REINDEX 命令來重建索引，來充分利用索引去重複項的優勢。
爲了說明 B樹 Deduplication 對索引大小的影響，可創建一個包含唯一列和非唯一列的表，填充1M行。在每列上創建兩個B樹索引，一個啓用 Deduplication，另一個禁用 Deduplication：
db=# CREATE test_btree_dedup (n_unique serial, n_not_unique integer);
CREATE TABLE
db=# INSERT INTO test_btree_dedup (n_not_unique)
SELECT (random() * 100)::int FROM generate_series(1, 1000000);
INSERT 0 1000000
db=# CREATE INDEX ix1 ON test_btree_dedup (n_unique) WITH (deduplicate_items = OFF);
CREATE INDEX
db=# CREATE INDEX ix2 ON test_btree_dedup (n_unique) WITH (deduplicate_items = ON);
CREATE INDEX
db=# CREATE INDEX ix3 ON test_btree_dedup (n_not_unique) WITH (deduplicate_items = OFF);
CREATE INDEX
db=# CREATE INDEX ix4 ON test_btree_dedup (n_not_unique) WITH (deduplicate_items = ON);
CREATE INDEX
我們比較下四個索引的大小：
可以看到，Deduplication對唯一索引沒有影響，但對有重複值的索引卻有重大影響。不巧的是，由於當時 PostgreSQL 13 剛推出，我們的雲提供商未提供支持，因此我沒使用Deduplication來清除空間。
清除表中的Bloat
就像在索引中一樣，表也可能包含死元組，可能會導致碎片化。與包含關聯表中數據的索引不同，不能僅簡單地重新創建表。要重新創建表，必須創建一個新表，遷移數據，同步數據，在其他表中創建所有索引……等完成這操作後，才能將舊錶切換爲新表。
有幾種方法可以重建表：
重新創建表：如上所述，使用這種方法通常需要大量的開發工作，尤其是在重建正在使用表的情況下。
清理表：PostgreSQL 提供 VACUUM FULL 命令回收表中死元組佔用的空間的方法（https://www.postgresql.org/docs/current/sql-vacuum.html）
-- Will lock the table
VACUUM FULL table_name;
上面兩種方法需要大量的精力或需要停機一段時間，這兩種用於重建表的內置選項都不理想。
使用pg_repack
pg_repack 是一種在不停機的情況下重建表和索引較好的解決方案。創建擴展名來使用pg_repack：
CREATE EXTENSION pg_repack;
rebuild 表和索引：
$ pg_repack -k --table table_name db_name
爲了在不停機的情況下重建表，該擴展程序將創建一個新表，將原始表中的數據加載到該表中，同時使其與新數據保持最新，然後再重建索引。該過程完成後，將切換兩個表並刪除原始表：https://reorg.github.io/pg_repack/#details
使用pg_repack重建表時注意兩點：
所需的存儲量大約爲要重建表的容量：該擴展會創建另一個表來將數據複製到該表，因此它需要的附加存儲量約爲表及其索引的大小。
可能需要手動清理：如果rebuild過程失敗或手動停止，可能會留下一些東向西，需手動清理。
在不停機 pg_repack 下重建表和索引，需額外的存儲空間才能運行，所以當你已經沒有存儲空間時，這不是一個好選擇。你需要先檢查看看是否有可用的存儲空間。
繼續清除
看到這，我們已經使用了所有的常規技術來清理了很多空間，但是……還有更多的空間可以刪除！重建索引後，在查看索引大小時，有件趣事引起我們注意。
我們其中較大的表是存儲交易數據：用戶付款後，可選擇取消退款。這種情況很少發生，只有一小部分交易被取消。
在這個交易表，既有購買用戶又有取消用戶的外鍵，並且每個字段都定義了一個B樹索引。採購用戶對此具有 NOT NULL 約束，因此所有行均具有值。另一方面，取消用戶可以爲空，只有一小部分行保存任何數據，取消用戶字段中的大多數值均爲NULL。
我們希望取消用戶的索引比購買用戶的索引小得多，但原來它們是完全相同的。之前我總是被教導說 NULL 不被索引，但是在PostgreSQL中卻被索引！這個“ Aha”時刻讓我們意識到，之前無緣無故寫了許多不必要的索引值。
這是我們爲取消用戶提供的原始索引：
CREATE INDEX transaction_cancelled_by_ix ON transactions(cancelled_by_user_id);
下面用不包含空值的部分索引替換了索引：
DROP INDEX transaction_cancelled_by_ix;
CREATE INDEX transaction_cancelled_by_part_ix ON transactions(cancelled_by_user_id)
WHERE cancelled_by_user_id IS NOT NULL;
重新索引後的完整索引大小爲769MB，空值超過99％。排除空值的部分索引小於5MB，減少了該指標的 99％ 以上！
爲了確保不需要這些 NULL 值，我們重置了表上的統計信息，等了一段時間後，我們發現索引的使用就像舊索引一樣！我們僅削減了超過 760MB 的未使用索引元組，並沒有影響性能！
利用部分索引
一旦我們嚐到了局部索引的“甜頭”後，我們就會發現還會有更多這樣的索引。爲了找到他們，我們寫了一個查詢來搜索具有high字段的索引null_frac，PostgreSQL估計的列值百分比爲NULL：
-- Find indexed columns with high null_frac
SELECT
c.oid,
c.relname AS index,
pg_size_pretty(pg_relation_size(c.oid)) AS index_size,
i.indisunique AS unique,
a.attname AS indexed_column,
CASE s.null_frac
WHEN 0 THEN ''
ELSE to_char(s.null_frac * 100, '999.00%')
END AS null_frac,
pg_size_pretty((pg_relation_size(c.oid) * s.null_frac)::bigint) AS expected_saving
-- Uncomment to include the index definition
--, ixs.indexdef
FROM
pg_class c
JOIN pg_index i ON i.indexrelid = c.oid
JOIN pg_attribute a ON a.attrelid = c.oid
JOIN pg_class c_table ON c_table.oid = i.indrelid
JOIN pg_indexes ixs ON c.relname = ixs.indexname
LEFT JOIN pg_stats s ON s.tablename = c_table.relname AND a.attname = s.attname
WHERE
-- Primary key cannot be partial
NOT i.indisprimary
-- Exclude already partial indexes
AND i.indpred IS NULL
-- Exclude composite indexes
AND array_length(i.indkey, 1) = 1
-- Larger than 10MB
AND pg_relation_size(c.oid) > 10 * 1024 ^ 2
ORDER BY
pg_relation_size(c.oid) * s.null_frac DESC;
查詢結果爲：
tx_cancelled_by_ix 是具有許多空值的大型索引：此處潛力巨大！
tx_op_1_ix 是大索引，幾乎沒有空值：潛力不大
tx_token_ix 是帶有少量空值的小索引：不管它
tx_op_name_ix 是沒有空值的大索引：沒啥用
結果表明，通過將tx_cancelled_by_ix變成不包含null的部分索引，可節省約1.3GB。
從索引中排除空值是否總是有好處？NULL和任何其他值一樣有意義。如果查詢使用了 IS NULL，這些查詢可能會受益於索引NULL。
這個方法僅對空值有用？使用部分索引排除不經常查詢或根本不查詢的值可能有益於任何值，而不僅僅是空值。NULL通常表示缺少值，我們沒有很多查詢在搜索空值，因此將它們從索引中排除是有意義的。
你最終如何清除超過20GB的空間呢？你可能已經注意到，上文提到了超過20GB的可用空間，但是圖表僅顯示一半，那就將索引從複製中刪除！從主數據庫釋放10GB時，每個副本的存儲量也大致相同。
Django ORM遷移
爲了將上述技術與Django一起使用，需要注意幾件事：
防止隱式創建外鍵索引
除非明確設置db_index=False，否則Django會在models.ForeignKeyfield上隱式創建B樹索引。
from django.db import models
from django.contrib.auth.models import User
class Transaction(models.Model):
# ...
cancelled_by_user = models.ForeignKey(
to=User,
null=True,
on_delete=models.CASCADE,
)
這個模型用來跟蹤交易數據，如果交易被取消，可保留對取消交易的用戶引用。如前所述，大多數交易不會被取消，因此我們設置null=True。
我們沒有顯式設置db_index，因此Django將在該字段上隱式創建完整索引。要創建部分索引，可進行以下更改：
from django.db import models
from django.contrib.auth.models import User
class Transaction(models.Model):
# ...
cancelled_by_user = models.ForeignKey(
to=User,
null=True,
on_delete=models.CASCADE,
db_index=False,
)
class Meta:
indexes = (
models.Index(
fields=('cancelled_by_user_id', ),
name='%(class_name)s_cancelled_by_part_ix',
condition=Q(cancelled_by_user_id__isnull=False),
),
)
我們告訴Django先不要在FK字段上創建索引，然後使用來添加部分索引models.Index。
爲了防止這類隱式功在不引起我們注意的情況下潛入索引，我們創建了Django檢查來強制自己始終顯式設置外鍵db_index。
將現有的完整索引遷移到部分索引
在遷移過程中，我們面臨的挑戰之一是用部分索引替換現有的完整索引，但要注意不會導致遷移期間的停機或性能下降。在確定了要替換的完整索引後，執行以下步驟：
用部分索引替換完整索引：如上所示，調整相關的Django模型並用部分索引替換完整索引。Django生成的遷移將首先禁用FK約束（如果該字段是外鍵），則刪除現有的完整索引並創建新的部分索引。執行此遷移可能會導致停機和性能下降，我們實際上不會運行它。
手動創建部分索引：使用Django的./manage.py sqlmigrate實用程序生成用於遷移的腳本，僅提取CREATE INDEX語句並進行調整以創建索引CONCURRENTLY，並在數據庫中手動創建索引。由於沒刪除完整索引，因此查詢仍可以使用它們，在這個過程中不影響性能。在Django遷移中同時創建索引，我們建議最好手動進行。
重置完整索引統計信息計數器：爲了確保刪除完整索引的安全性，我們首先要確保正在使用新的部分索引。爲了跟蹤它們的使用，我們使用重置完整索引的計數器pg_stat_reset_single_table_counters(<full index oid>)。
顯示器使用部分索引：重置統計信息後，我們監測pg_stat_all_indexes表中
的idx_scan，idx_tup_read、idx_tup_fetch，來觀察整體查詢性能和部分索引使用情況。
刪除完整索引：一旦使用了部分索引，就刪除完整索引。這是檢查部分索引和完全索引大小的好方法，以便確定要釋放多少存儲空間。
僞造Django遷移：一旦數據庫狀態有效地與模型狀態同步，我們就使用僞造遷移./manage.py migrate --fake。僞造遷移時，Django會將遷移註冊爲已執行，但實際上不會執行任何操作。當需要更好地控制遷移過程時，這種情況很有用。請注意，在沒有停機時間考慮的其他環境，Django遷移將正常執行，並全部索引將替換爲部分索引。
在本文中，我們清除了很多存儲空間：
刪除未使用的索引
重新打包表和索引（在可能的情況下激活B樹重複數據刪除）
利用部分索引僅對必要內容進行索引
原文鏈接：https://hakibenita.com/postgresql-unused-index-size
本文爲AI科技大本營翻譯，轉載請註明來源出處。
更多精彩推薦
☞打造 AI 語音新標杆，英特爾與騰訊雲小微創新共贏
☞三種方法，用Python輕鬆提取PDF中的全部圖片
☞這25條極簡Python代碼，你還不知道
☞告別手敲 SQL ？GPT-3 自動幫你寫
點分享點收藏點點贊點在看