對于中文版的SQL SERVER，默認安裝后使用的默認排序規則為Chinese_PRC_CI_AS，在此排序規則下，使用varchar類型來可以“正常存取”存放中文字符以及一些東南亞國家的字符，同時varchar類型在存放英文字符和數字時比nvarchar節省一半的存儲空間，因此很多DBA都習慣使用varchar類型來存放字符數據，但這樣便存在一些亂碼隱患！
首先是特殊字符如上下標或版權字符，測試Code如下：

--準備測試表
DROP TABLE TB1
GO
CREATE TABLE TB1 
(
C1 VARCHAR(200),
C2 NVARCHAR(200)
)
GO
--插入測試數據
INSERT INTO TB1(C1,C2)
SELECT N'm2',N'm2'
UNION
SELECT N'?',N'?'
--查詢
SELECT C1,
CAST(C1 AS NVARCHAR(200)) AS C1_N,
C2,
CAST(C2 AS VARCHAR(200)) AS C2_V
FROM  TB1

測試結果如下：

可以明顯地看到上標在varchar類型下轉換成普通數字2，而版權符號在varchar類型下直接就亂碼。

對于這些特殊字符，可能不會被使用到，比如用戶姓名字段，那么是不是就可以使用varchar類型了呢?

當然不是，能避開特殊字符，還得考慮“有文化的父母”給子女來點生僻字以展示有文化！！！比如五代十國中南漢的創建者劉?就自認為很牛叉，于是自己創了一個“?”字，取意為飛龍在天，如此牛叉的意義就不招varchar的“喜歡”，測試code如下：測試結果如下：

可以明顯地看到上標在varchar類型下轉換成普通數字2，而版權符號在varchar類型下直接就亂碼。

對于這些特殊字符，可能不會被使用到，比如用戶姓名字段，那么是不是就可以使用varchar類型了呢?

當然不是，能避開特殊字符，還得考慮“有文化的父母”給子女來點生僻字以展示有文化！！！比如五代十國中南漢的創建者劉?就自認為很牛叉，于是自己創了一個“?”字，取意為飛龍在天，如此牛叉的意義就不招varchar的“喜歡”，測試code如下：

INSERT INTO TB1(C1,C2)
SELECT N'劉?',N'劉?'

SELECT C1,
CAST(C1 AS NVARCHAR(200)) AS C1_N,
C2,
CAST(C2 AS VARCHAR(200)) AS C2_V
FROM  TB1

顯示結果如下：

“?”字只能在NVARCHAR模式下才能完好地顯示哈！

建議使用NVARCHAR來存放非英文字符數據理由：
理由1：VARCHAR類型存放特殊字符或生僻字時存在亂碼或字符被轉變的問題
理由2：對于中文字符，使用VARCHAR和NVARCHAR消耗同樣的空間，對于英文字符，使用VARCHAR比NVARCHAR節省一倍的空間，但隨著磁盤成本越來越低，其提升的性能和節省的成本有限。（例外：如果數據中存在大量英文字符和少量非英文字符，則可以考慮VARCHAR類型）
理由3：對于需要國際化的企業，后期將VARCHAR升級為NVARCHAR的成本太高或難以實現
理由4：使用VARCHAR存放非英文字符時，容易生成錯誤的預估值，尤其在執行LIKE這類前綴匹配的預估時。顯示結果如下： 

“?”字只能在NVARCHAR模式下才能完好地顯示哈！
建議使用NVARCHAR來存放非英文字符數據理由：
理由1：VARCHAR類型存放特殊字符或生僻字時存在亂碼或字符被轉變的問題
理由2：對于中文字符，使用VARCHAR和NVARCHAR消耗同樣的空間，對于英文字符，使用VARCHAR比NVARCHAR節省一倍的空間，但隨著磁盤成本越來越低，其提升的性能和節省的成本有限。（例外：如果數據中存在大量英文字符和少量非英文字符，則可以考慮VARCHAR類型）
理由3：對于需要國際化的企業，后期將VARCHAR升級為NVARCHAR的成本太高或難以實現
理由4：使用VARCHAR存放非英文字符時，容易生成錯誤的預估值，尤其在執行LIKE這類前綴匹配的預估時。