# 54.4\. 索引鎖的考量 索引訪問方法必須支持多個進程對索引的并發更新。 在索引掃描期間，PostgreSQL核心系統在索引上抓取 `AccessShareLock` ，并且在更新索引期間(包括`VACUUM`)也會抓取`RowExclusiveLock`。 因為這些鎖類型不會沖突，所以訪問方法有責任處理任何它自己需要的更細致的鎖需求。 把整個索引鎖住的排他鎖只是在創建和刪除索引或者`REINDEX`的時候使用。 創建一個支持并發更新的索引類型通常要求對所需的行為進行廣泛的并且細致的分析。 對于 b-tree 和 Hash 索引類型，你可以讀取在 `src/backend/access/nbtree/README`和 `src/backend/access/hash/README`里面描述的設計決策。 除了索引自己內部的一致性要求之外，并發更新產生了一些有關父表(_堆_)和索引之間的一致性問題。 因為PostgreSQL是把堆的訪問和更新與索引的訪問和更新分開的。 用下面的規則處理這樣的問題： * 在制作一行的索引記錄之前，先做堆記錄。 （因此并發的索引掃描很可能看不到堆記錄。 這么做應該是 OK 的，因為索引讀者應該對未提交的行不感興趣。 不過需要看看[Section 54.5](#calibre_link-1170)。） * 如果一條堆記錄要被刪除(被 `VACUUM`)，所有其索引記錄都必須首先刪除。 * 對于并發索引類型，一次索引掃描必須在保存有`amgettuple` 最后返回記錄的索引頁面上維護一個銷，而`ambulkdelete` 不能刪除其它后端用銷固定的索引頁面里面的記錄。 為何需要這條規則在下面解釋。 如果沒有第三條規則，那么一個索引讀者是可能在一條索引記錄剛要被`VACUUM`刪除之前看到它， 然后在對應的堆記錄已經被`VACUUM`刪除時，去找這條堆記錄。 如果讀者到達該項時，該項編號仍然沒有使用，那么這種情況不會導致嚴重的問題，因為空的項槽位會被`heap_fetch()`忽略。 但是如果第三個后端已經為其它什么東西復用了這個項槽位又如何? 如果使用 MVCC 兼容的快照，那么就不會有問題，因為新占據的槽位當然是太新了，因而無法通過快照測試。 但是，對于非 MVCC 兼容的快照(比如`SnapshotNow`)，那么就有可能接受并返回一個實際上并不匹配掃描鍵字的行。 可以通過要求掃描鍵字在所有場合下都重新檢查的方法來避免這種情況，但是這種方法開銷太大了。 取而代之的是，通過在索引頁面上使用一個銷，當作一個代理，告訴系統說，讀者可能還在對應堆記錄的索引記錄上空"飛行"。 讓`ambulkdelete`在這樣的銷上阻塞可確保`VACUUM`無法在讀者完成讀取之前刪除堆記錄。 這種解覺辦法只增加了一點點運行時開銷，并且只是在非常罕見的實際有沖突的情況下才導致阻塞開銷。 這個解決方法要求索引掃描必須是"同步的"：必須在掃描完對應的索引記錄之后馬上抓取每個堆記錄。 這樣的方案開銷比較大，原因有若干個。 而"異步的"掃描，可以先從索引里收集很多 TID ，然后在稍后的某個時間訪問堆行，這樣就會繞開很多索引鎖的開銷，以及可以允許更有效的堆訪問模式。 但是按照上面的分析，在非 MVCC 兼容快照上必須使用同步方法，而對使用 MVCC 快照的查詢，使用異步掃描應該是可行的。 在`amgetbitmap`索引掃描里，訪問方法不需要保證在任何返回的行上保持一個銷。 畢竟，除了給最后一個行加銷之外，也沒法給其它的加。 因此，只能在 MVCC 兼容的快照里使用這樣的掃描。 如果沒有設置`ampredlocks`，任何在可串行化事務中使用這個索引訪問方法的掃描將會在整個索引上獲得一個非阻塞的謂詞鎖。 與其并發的另一個可串行化事務向這個索引中插入任何一個元組時都會引發一個讀寫沖突。 如果在并發的可串行化事務間檢測到某種模式的讀寫沖突，為了保證數據一致性其中一個事務可能會被取消。 如果設置了這個標志，表明這種索引訪問方法實現了精細的謂詞鎖，因而趨向于削減這種事務取消的頻度。