在SQL Server中更改列varchar（255）nvarchar

Question

我正在使用SQL Server 2008 Express，我們的一些列被定義爲varchar（255）。我應該將這些列轉換爲NvarChar（255）還是nvarchar（max）？

我問的原因是我讀取unicode字符的nvarchar（255）實際上會存儲1/2字符數（因爲unicode字符是2個字節），而使用varchar（）255則允許我存儲255個字符（或者它是255-2的偏移量）。

是否會有使用nvarchar（max）的任何性能命中？

JDS

Answer 1

嘛，不是很 - 轉換爲nvarchar（255）不削減存儲在一半的字符數 - 它仍然存儲255個字符。它只需要兩倍的空間（510字節與255字節）。

應該轉換到NVARCHAR - 儘管它使用兩倍的空間所有的時間 - 如果你：

• 需要支持阿拉伯文，希伯來文，西里爾文，或任何東亞語言 - 只在Unicode將能夠實際捕獲這些字符
• 需要支持其他使用「標準」拉丁字母但具有特殊字符的語言 - 東歐（斯拉夫語）語言等東西（č ă ě） - 這些字符將被存儲正如c, a, e中的varchar（）字段

NVarchar（max）是一個不錯的選擇 - 如果你真的需要高達2 GB的文本。使所有字符串字段nvarchar（max）只是「一致」是一個非常糟糕的主意 - 您將遇到巨大的性能問題。請參閱Remus Rusanu的article on the topic

Answer 2

對於您使用的每種數據類型，您都應該有某種理由。

nvarchar（255）（在SQL Server中）存儲255個Unicode字符（510個字節加開銷）。

在varchar列中存儲普通的UTF-8編碼的Unicode數據當然是可能的 - 在源文件中每個字節一個varchar字符（UTF-8將對多個字符適當地使用多個字節）。在這種情況下，普通的ASCII數據每個字符只使用1個字節，所以你沒有雙字節開銷。它有很多缺點，其中最重要的一點就是數據庫不再可以對排序和其他字符處理工作起到很大的幫助，因爲數據可能被編碼。但是，就像我說的那樣，這是可能的。

我推薦適當長度的char或varchar字符，例如帳號可能因爲零填充問題，許可證號碼，發票號碼（帶字母），郵政編碼，電話號碼等原因而不能使用。是從不包含任何寬字符的列的類型，並且通常僅限於羅馬字母和數字，有時甚至不是標點符號，並且通常被嚴重索引。對於表和索引中的列以及數據庫引擎中的工作集中的所有這些字符，額外NUL高字節的開銷絕對沒有必要。

我推薦nvarchar用於像名字和地址等東西，在可能有寬字符的地方，或許即使在近期內沒有可預見的用法。

我通常從不使用nchar--我從來不需要短代碼（通常是我選擇char列的地方），它需要寬字符。

在所有情況下，真正應該充分考慮長度（或最大）使用情況。我絕對不會使用名稱或地址的最大值，並且基準測試中的開銷可能很明顯。我已經看到在查詢的中間階段投射到varchar（長度）顯着提高了性能。