Microsoft SQL Server中條件字段是Nvarchar類型的，條件有中文的無法查詢的原因及處理方法

條件中帶的是中文無法查詢出，因為字段sender_su_name是nvarchar類型的，需要前面接個N

SELECT * FROM [test].[dbo].[Ship_User_Email]  WHERE [sender_su_name]=N'獎勵'

為什么要帶Ｎ如下解釋：

使用 Unicode 數據

Unicode 標準為全球商業領域中廣泛使用的大部分字符定義了一個單一編碼方案。所有的計算機都用單一的 Unicode 標準 Unicode 數據中的位模式一致地翻譯成字符。這保證了同一個位模式在所有的計算機上總是轉換成同一個字符。數據可以隨意地從一個數據庫或計算機傳送到另一個數據庫或計算機，而不用擔心接收系統是否會錯誤地翻譯位模式。

對于用一個字節編碼每個字符的數據類型，存在的問題之一就是此數據類型只能表示 256 個不同的字符。這就迫使對于不同的字母表（例如相對較小的歐洲字母表）采用多重編碼規格（或者代碼頁）。而且也不可能處理象日文漢字或韓國文字這樣具有數千個字符的字母表。

每個 Microsoft? SQL Server? 排序規則都有一個對表示 char、varchar 和 text 值中的每個字符定義位模式進行定義的代碼頁。可為個別的列和字符常量指派不同的代碼頁。客戶端計算機使用與操作系統區域設置相關聯的代碼頁解釋字符位模式。有很多種不同的代碼頁。一些字符出現在某些代碼頁上，但并不出現在其它的代碼頁上。某些字符在一些代碼頁上用一個位模式定義，而在其它的代碼頁上卻用另一個位模式定義。當您設計必須處理不同語言的國際性系統時，為了滿足不同國家/地區的語言需求，給所有的計算機挑選代碼頁就變得困難了。要保證每一臺計算機與使用不同代碼頁的系統交互時都進行正確的翻譯也是困難的。

Unicode 規格通過采用兩個字節編碼每個字符使這個問題迎刃而解。轉換最通用商業語言的單一規格具有足夠多的 2 字節的模式 (65,536)。因為所有的 Unicode 系統均一致地采用同樣的位模式來代表所有的字符，所以當從一個系統轉到另一個系統時，將不會存在未正確轉換字符的問題。通過在整個系統中使用 Unicode 數據類型，可盡量減少字符轉換問題。

在 Microsoft SQL Server 中，以下數據類型支持 Unicode 數據： 

nchar

nvarchar

ntext 

說明  這些數據類型的前綴 n 來自 SQL-92 標準中的 National（Unicode）數據類型。

nchar、nvarchar 和 ntext 的用法分別與 char、varchar 和 text 的用法一樣，但在以下方面不同： 

Unicode支持的字符范圍更大。

存儲 Unicode 字符所需要的空間更大。

nchar 和 nvarchar 列最多可以有 4,000 個字符，而不象 char 和 varchar 字符那樣可以有 8,000 個字符。

Unicode 常量使用 N 開頭來指定：N'A Unicode string'。

所有 Unicode 數據都使用相同的 Unicode 代碼頁。排序規則不控制用于 Unicode 列的代碼頁，僅控制比較規則和是否區分大小寫等特性。