# 54.5\. 索引唯一性檢查 PostgreSQL使用_唯一索引_來強制 SQL 唯一約束，唯一索引實際上是不允許多條記錄有相同鍵值的的索引。 一個支持這個特性的訪問方法要設置`pg_am`.`amcanunique`為真。（目前，只有 b-tree 支持它。） 因為 MVCC ，必須允許重復的條目物理上存在于索引之中：該條目可能指向某個邏輯行的后面的版本。 實際想強制的行為是，任何 MVCC 快照都不能包含兩條相同的索引鍵字。 這種要求在向一個唯一索引插入新行的時候分解成下面的幾種情況： * 如果一個有沖突的合法行被當前事務刪除，這是可以的。 （特別是因為一個 UPDATE 總是在插入新版本之前刪除舊版本，這樣就允許一個行上的 UPDATE 不用改變鍵字進行操作。） * 如果一個在等待提交的事務插入了一行有沖突的數據，那么準備插入數據的事務必須等待看看改事務是否提交。 如果該事務回滾，那么就沒有沖突。如果它沒有刪除沖突行然后提交，那么就有一個唯一性違例。 （實際上只是等待另外那個事務結束，然后在程序里重做可視性檢查。） * 類似的，如果一個有沖突的有效行被一個準備提交的事務刪除，那么另外一個準備提交的插入事務必須等待該事務提交或者退出，然后重做測試。 此外，根據上面的規則報告唯一性違反前，訪問方法必須重新檢查剛被插入的行是否仍然"活著"。 如果這一行已經因為事務的提交而"死掉了"，那么不應當發出任何錯誤。 (這種情況不可能出現在插入一個由當前事務創建的行的普通場景下。 但是在`CREATE UNIQUE INDEX CONCURRENTLY`的過程中是可能的。） 我們要求索引訪問方法自己進行這些測試，這就意味著它必須檢查堆，以便查看那些根據索引內容表明有重復鍵字的任意行的提交狀態。 這樣做毫無疑問地很難看并且也不是模塊化的，但是這樣可以節約重復的工作： 如果我們實施分離的探測，那么，當查找新行的索引項的插入位置時，必須重復對沖突行的索引查找。 并且，沒有很顯然的方法來避免競爭條件，除非沖突檢查是插入新索引項的整體動作的一部分。 如果唯一性約束是可延期的，情況將更加復雜：我們需要能夠為新行插入一個新的索引項， 但推遲任何唯一性違反的錯誤，直到語句結束甚至更晚。 為了避免不必要的重復搜索索引，索引訪問方法應該在初始插入時做一個初步的唯一性約束檢查。 如果結果明確地顯示沒有和活著的元組沒有沖突，那么事情已經完成了。 否則當需要實施這個約束時，我們需要調度一個再檢查。 如果再檢查時，被插入的元組和有著相同鍵的其他元組都還活著，那么必須報告錯誤。 （為此，"活著"實際上意味著"在該索引項的HOT鏈上的任何一個元組還活著"。） 為了實現這個，`aminsert`函數被傳入擁有下列某一個值的`checkUnique`參數： * `UNIQUE_CHECK_NO`指示不檢查唯一性約束（這是一個非唯一索引）。 * `UNIQUE_CHECK_YES`指示這是一個非可推遲唯一性約束，并且正如上面描述的必須立即檢查唯一性約束。 * `UNIQUE_CHECK_PARTIAL`指示這個唯一性約束是可延期的。 PostgreSQL將使用這種模式插入每一行的索引項。 訪問方法必須允許在索引中插入重復的項目，并且通過讓`aminsert`返回FALSE報告任何潛在的重復。 對每一個返回FALSE的行，一個延期的再檢查將會被調度。 訪問方法必須識別任何可能違反唯一性約束的行，但是對它來說把不違反唯一性約束的行報告成可能違反并不是一個錯誤。 這允許不必等待其他事務完成就可以完成檢查；在這里被報告的沖突不被當成錯誤并且將在以后進行再檢查，那時沖突可能已經消失了。 * `UNIQUE_CHECK_EXISTING`指示這是對一個被報告有潛在唯一性違反的行的被延期的再檢查。 盡管是通過調用`aminsert`函數，這種情況下訪問方法必須_不能_插入新的索引項。 相應的索引項已經存在了。當然，訪問方法必須檢查是否有另一個活著的索引項。 如果有并且目標行仍然活著的話報告錯誤。 `UNIQUE_CHECK_EXISTING`被調用時，建議訪問方法進一步去確認目標行已經在索引中有一個索引項，如果沒有則報錯。 這是個好的做法，因為傳入`aminsert`的索引元組的值可能被重新計算。 如果索引定義涉及不是真正不可變（immutable）的函數，我們可能會在索引中錯誤的區域查找。 檢查目標行可以在再檢查中被找到確保我們正在掃描原始插入時使用的相同的元組值。