SQL Server 查詢計劃雜湊衝突
我想知道是否有人可以闡明我的擔憂，即
query_plan_hash碰撞可能導致查詢作為完全不同的查詢執行。雜湊是一個 16 位的十六進制，
sp_help sys.dm_exec_query_stats表示二進制。因此它只是一個 64 位散列，而且很可能發生衝突（考慮到 SHA1$$ 160 bit $$剛剛被證實有碰撞）。
plan_hash和query_plan_hash兩者是否必鬚髮生衝突（查詢作為完全不同的查詢執行）才能發生？我也很好奇 SQL Server 中是否有一個設置允許我們將此雜湊更改為 SHA2-512（以減少發生衝突的可能性）。我們的數據非常重要。
我通過 Google 和 Stack Exchange 論壇進行了高低搜尋。
既不
query_hash也不query_plan_hash用於查找查詢計劃以執行，因此不會出現問題中的確切問題。的文件
sys.dm_exec_query_stats解釋說：
query_hash提供以允許使用者匯總僅因文字值不同的查詢（將參數化為相同形式的查詢）的資源使用情況。query_plan_hash提供以允許使用者計算具有相似執行計劃的查詢的累積成本。不出所料，SQL Server 開發人員竭盡全力確保僅在安全的情況下重用記憶體的計劃。這遠遠超出了記憶體計劃必須與“查詢”完全匹配的明顯要求。
簡要地：
SQL Server 有多個計劃記憶體儲存，每個都以雜湊表的形式實現。雜湊值和記憶體鍵對用於將編譯計劃與特定“查詢”連接起來。
雜湊值為
(database_id * object_id) mod (hash table size)。_ 這決定了特定記憶體儲存中的雜湊桶。這object_id是過程、函式和触發器等對象的已知元數據。對於 ad-hoc SQL，它object_id是整個批處理文本的雜湊值。記憶體計劃必須匹配以匹配“查詢”的屬性集合稱為記憶體鍵。這用於在雜湊桶中查找並確認*完全匹配。*一些（不是全部）記憶體鍵屬性可以在sys.dm_exec_plan_attributes的文件中找到。
重要的是，對於 ad-hoc SQL，整個批處理文本是記憶體鍵屬性之一。
更多詳細資訊可以在Microsoft SQL 可程式性和 API 開發團隊的3.0 How Cache Lookups Work（以及該系列中的其他文章）中找到。