如何在 SQL Server 上測量每秒的鍵查找次數
我正在努力減少在我們的 SQL Server 上進行密鑰查找的事務量。
首先，我想為該指標上的正常或可容忍數字定義一個基線，並且由於我們不斷在生產中發布版本，然後，我想創建一個基於它的自動化，當它向南時通知我。
我遇到的問題實際上是在perfmon或 SQL DMV 上找到正確的計數器來獲取數據。
我查看了明顯的對象SQL Server，訪問方法對象，但找不到特定的對象。我還嘗試了其他計數器或 SQL 視圖，但找不到它。
任何建議將不勝感激！
我不知道有一種完全準確和可靠的方法來跟踪它。
至少獲得一些可能有用的東西的一種方法是保留sys.dm_db_index_usage_stats的快照，特別是
user_lookupsindex_id 0（RID 查找）和 1（鍵查找）的列。可以出於多種原因重置此 DMV，包括數據庫或實例重新啟動。重建（但不是重組）和索引還會清除 SQL Server 2012 及更高版本上的相關 DMV 條目，這會使事情變得更加困難。您將需要相當定期地擷取資訊並使用啟發式方法來確定 DMV 是否在擷取之間重置。索引使用統計 DMV 也只返回包含 Lookup 的計劃執行次數的計數。包含單個 Key Lookup 的計劃將使計數器增加 1，而不管實際執行的查找次數如何。即使 Lookup 根本沒有執行，它也會增加。
sys.dm_db_index_operational_stats DMV 記錄了實際執行的單例查找的數量，但不區分直接在索引上的單例查找以及由鍵或 RID 查找產生的查找，因此它對您的目的沒有用處。
單例搜尋是訪問方法對象報告的探測掃描的另一個名稱。無法區分唯一索引上的“正常”單例查找和查找產生的單例查找。這意味著訪問方法探測掃描計數器對您沒有用處。無論如何，AM 計數器非常嘈雜，並且無法將計數器與特定索引相關聯。
Michael J. Swart 的一篇好文章似乎表明，
Probe Scans/sec在 Access 方法下，密鑰查找將計入計數器：鍵查找（Showplan Operator 文件）
此運算符也稱為書籤查找運算符。它始終計入 Probe Scans/sec 性能計數器。有趣的是，即使它一次只獲得一條記錄，該運算符也經常被視為性能不佳的症狀。那是因為處決的數量可能會很大。許多執行可能會降低查詢的性能。如果您關注性能計數器，您會注意到這些執行中的每一個都將計入 Probe Scans 性能計數器。
雖然使用性能計數器只會給你一個數字。您仍然需要深入計劃記憶體以查找具有鍵查找的特定查詢。這是可能的。
注意：上面指向 showplan 運算符的連結是 Michael 所連結的，但我碰巧在 MSDN 中找到了提供更多最新資訊的目前文件：Showplan Logical and Physical Operators Reference