本文介紹了哈希不匹配的處理方法，對大家解決問題具有一定的參考價值，需要的朋友們下面隨著小編來一起學習吧！
問題描述
我正在散列相同的值，但得到不同的結果。
這里有一個簡單的例子來解釋我遇到的問題：
我有一個維度表，如下所示：
| 性別 | Gender_id |
|---|---|
| 男性 | 1 |
| 女性 | 0 |
性別的數據類型為NVARCHAR(6)，Gender_id為int
當我執行以下任何查詢時，我都會得到相同的哈希：
**Scenario 1:**
SELECT
CONVERT(BINARY(20), HASHBYTES('Md5', Concat(Gender, cast(gender_id as int))))
FROM demographic
WHERE gender = 'Male';
輸出：‘0x6B216D8BB993AA263265CCF645C282B100000000’
**Scenario 2:**
SELECT
CONVERT(BINARY(20), HASHBYTES('Md5', Concat(Gender, CAST(gender_id AS NVARCHAR(1)))))
FROM demographic
WHERE gender = 'Male';
輸出：‘0x6B216D8BB993AA263265CCF645C282B100000000’
在場景1中，我將Gender_id強制轉換為int，在場景2中，我將Gender_id強制轉換為NVARCHAR。在這兩種情況下，哈希是相同的。
當我執行查詢調用維度中的特定值而不是列時，我的哈希是不同的：
**Scenario 3:**
SELECT CONVERT(BINARY(20), HASHBYTES('MD5', Concat('Male', CAST(1 as INT))));
輸出：‘0x048A5F0EE2D2B4070CFF8A38CB6DAC7100000000’
**Scenario 4:**
SELECT CONVERT(BINARY(20), HASHBYTES('MD5', Concat('Male', CAST(1 as NVARCHAR(1)))));
輸出：‘0x6B216D8BB993AA263265CCF645C282B100000000’
在場景3中，我將1強制轉換為int，就像我在場景1中所做的那樣。在場景4中，我像在場景2中所做的那樣，將1強制轉換為NVARCHAR。然而，場景3和4具有不同的散列。除此之外，方案4的哈希與方案1和方案2的哈希一致。
我很難理解為什么場景1、2和4的散列相同，而場景3的散列不同。在我的維度中，Gender_id是一個int。當我查詢我的維度時，無論我如何轉換它，散列總是相同的。在場景3和場景4中，當我用實際值替換列名時，結果會發生變化。場景3中的散列將與場景1和場景2不匹配，除非我將其轉換為NVARCHAR。為什么會這樣呢？因為Gender_id自然是整型的？
如果您有任何見解，我將不勝感激，如果需要，我很樂意提供更多說明。
謝謝！
推薦答案
'Male'是ANSI值，而不是Unicode值。對于Unicode，您需要N'Male'
例如，我在此查詢中得到以下結果：
select convert(varchar(20), cast('Male' as varbinary(20)), 1)
0x4D616C65
而這個，請注意在文字之前添加了N：
select convert(varchar(20), cast(N'Male' as varbinary(20)), 1)
0x4D0061006C006500
這篇關于哈希不匹配的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，
