為什麼還有 varchar 數據類型？
我的許多數據庫都有定義為 varchars 的欄位。自從我在美國生活和工作以來，這並不是什麼大問題（那裡唯一存在的語言是“美國”。啊哈）
在使用數據庫大約 5 年後，我發現我最終遇到了 varchar 欄位的有限性質的問題，我必須修改我的欄位以將數據儲存為 nvarchars。在不得不對錶進行另一次更新，將 varchar 欄位轉換為 nvarchar 之後，我想到了——為什麼我們仍然這樣做？我早就做出了將所有新的文本欄位定義為 nvarchar 的心理決定，而不是 varchar，這是我 10 年前在學校時從教科書中學到的。
現在是 2011 年，去年有一個新版本的 SQL Server。當我們可以/應該使用 nvarchar 時，為什麼我們繼續支持 varchar 數據類型？
我知道經常有人認為 nvarchars 是 varchars 的“兩倍大”，因此儲存空間的使用可能是維護 varcars 的一個論據。
但是，今天的使用者可以定義他們的 nvarchars 來將數據儲存為 UTF-8 而不是預設的 UTF-16，如果他們想節省儲存空間的話。如果主要需要，這將允許 8 位編碼，同時保證插入其數據庫的稀有 2-8 字節字元不會破壞任何內容。
我錯過了什麼嗎？在過去的 15 到 20 年裡這種情況沒有改變，有充分的理由嗎？
- varchar 工作對於許多西歐語言（挪威語、丹麥語、德語、法語、荷蘭語等）來說已經足夠好了，但會遇到一些整理問題
- 請參閱 SO varchar vs nvarchar 性能nvarchar 具有嚴重的性能影響
- 與處理日期 MDY 與 DMY 相比，這是微不足道的
除了解決標準和兼容性的答案外，還應該牢記性能。雖然磁碟空間很容易被接受為便宜，但 DBA/開發人員經常忽略查詢性能有時與表的行/頁大小直接相關的事實。使用
NVARCHAR而不是VARCHAR（在不必要時）將有效地使字元欄位的行大小加倍。例如，如果您有 5 個或 10 個 50 長度的欄位，那麼您說的是每行可能會增加 500 個字節。如果您有一個寬表，這可能會將每一行推入多個頁面並對性能產生不利影響。