隨着很少使用的值的基數減少，索引是否會變得不那么有效？

Question

給定一個具有數百萬行的 SqlServer 客戶表和 last_name 列上的索引，讓我們假設隨着時間的推移，由於客戶要求我們忘記他們，我們采取了通過替換 last_name（當然還有任何其他相關數據）具有 static 值，如“******”。 我們會這樣做，而不是刪除數據 b/c，因為我們需要保留相關數據以進行審計和其他正當的業務原因。

隨着時間的推移，如果我們發現這些行中有很大一部分以這種方式被匿名化，那么假設除了有人實際查詢 last_name 以星號，常見的情況是使用此索引的查詢將搜索合法的姓氏，例如 last_name 以“H”開頭的地方？

例如，索引的內部數據結構是否會受到影響，使得這個 ***** 值的不斷增長的記錄集可能會創建一個大的 memory 或頁面 object，這可能會在某些情況下導致 I/O 瓶頸或其他問題，例如就像數據庫服務器負載很重一樣？

我知道低基數索引並不是新的/不常見的，但是如果我們從一個高基數的索引開始並引入一個不斷增長的相同值重復的“腫瘤”，我想知道這是否最終會成為一個問題？

我敢肯定還有其他/更好的方法可以解決這個問題，如果您想解決更深層次的問題，我很高興聽到它們，但我仍然想了解對索引的潛在影響。

Answer 1

B-Tree 索引是平衡的，它們的整體結構（深度）僅取決於表的基數、鍵的長度和頁面的填充百分比。 因此，您不會將結構問題視為列的數據分布發生變化（假設您正在進行適當的索引維護。）

但是，這種傾斜的數據分布會導致統計問題。

考慮以下查詢：“ select... from Customer where LastName = @p ” 對於@p的所有可能值沒有最佳計划。 有些值會返回幾行，有些值會返回數百萬。

過濾索引CREATE IX ON CUSTOMER (LastName) WHERE LastName <> '***'部分解決了這個問題。 索引將只包含有趣的行，因此會更小。 可能需要進行一些查詢更改以確保實際使用此新索引...例如select... from Customer where LastName = @p and LastName <> '***' or select... from Customer where LastName = @p (option recompile) 。

SQL Server 2022（當前未發布）將引入“參數敏感計划優化”，它也試圖解決這個問題。