為什麼主鍵上的集群鍵查找每次執行的估計行數很高？

我們有一個帶有 Key Lookup 的查詢，它估計每次執行有數千行。據我了解，每次執行應該只有一行。我知道統計數據可能會產生誤導，但優化器不明白主鍵是唯一的嗎？

此查詢中涉及的表具有以下形式的聚集主鍵：

/****** Object:  Index [PK_Table_Name]    Script Date: 6/16/2021 9:52:12 AM ******/
ALTER TABLE [dbo].[Table_Name] ADD  CONSTRAINT [PK_Table_Name] PRIMARY KEY CLUSTERED 
(
   [Table_Name_ID] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO

據我了解，主鍵提供了對錶中單行的唯一引用。

因此，對於它在非聚集索引中找到的每一行，它應該能夠使用該索引對聚集索引的引用來檢索它需要滿足對它所作用的行的其餘查詢過濾所需的單行。（這是一個嵌套循環連接運算符。）

那麼為什麼它估計將近 4000 行將作為 Key Lookup 的一部分返回呢？（不是“所有執行”，大約 36,000,000 是 4000 行和它期望從非聚集索引查找中獲得的 9000 行的乘積。）

執行時統計數據顯示該聚集索引查找的 2851 行和 2851 次執行，這是我所期望的。

如果它有幫助，這是在 Azure SQL 數據庫中，具有@@version：

Microsoft SQL Azure (RTM) - 12.0.2000.8 
   Apr 29 2021 13:52:20 
   Copyright (C) 2019 Microsoft Corporation

查看 Paul White 的部落格文章Cardinality Estimation Bug with Lookups以獲得您問題的答案：

在 SSMS 執行計劃中，應用過濾謂詞的鍵或 RID 查找上的估計行數可能是錯誤的。

這個錯誤不會影響優化器的最終計劃選擇，但它看起來確實很奇怪。

該部落格文章繼續說，計劃在 2020 年 8 月進行修復，以在新的 160 兼容級別下解決此問題：

計劃在 SQL Server 2019（兼容級別 160）之後的版本中對此進行修復

引用自：https://dba.stackexchange.com/questions/294383