char、nchar、varchar、nvarchar，對比那個好

< DOCTYPE html PUBLIC -WCDTD XHTML StrictEN httpwwwworgTRxhtmlDTDxhtml-strictdtd>

資料庫定義到char類型的字段時，不知道大家是否會猶豫一下，到底選char、nchar、varchar、nvarchar、

text、ntext中哪一種呢？結果很可能是兩種，一種是節儉人士的選擇：最好是用定長的，感覺比變長能省些空

間，而且處理起來會快些，無法定長隻好選用定長，并且将長度設定盡可能地小；另一種是則是覺得無所謂，

盡量用可變類型的，長度盡量放大些。

鑒于現在硬體像蘿蔔一樣便宜的大好形勢，糾纏這樣的小問題實在是沒多大意義，不過如果不弄清它，

總覺得對不起勞累過度的CPU和硬碟。

下面開始了(以下說明隻針對SqlServer有效)：

1、當使用非unicode時慎用以下這種查詢：

             select f from t where f = N'xx'

     原因：無法利用到索引，因為資料庫會将f先轉換到unicode再和N'xx'比較

2、char 和相同長度的varchar處理速度差不多（後面還有說明）

3、varchar的長度不會影響處理速度！！！（看後面解釋）

4、索引中列總長度最多支援總為900位元組，是以長度大于900的varchar、char和大于450的nvarchar,nchar

将無法建立索引

5、text、ntext上是無法建立索引的

6、O/R Mapping中對應實體的屬性類型一般是以string居多，用char[]的非常少，是以如果按mapping的

合理性來說，可變長度的類型更加吻合

7、一般基礎資料表中的name在實際查詢中基本上全部是使用like '%xx%'這種方式，而這種方式是無法利用

索引的，是以如果對于此種字段，索引建了也白建

8、其它一些像remark的字段則是根本不需要查詢的，是以不需要索引

9、varchar的存放和string是一樣原理的，即length {block}這種方式，是以varchar的長度和它實際占用

空間是無關的

10、對于固定長度的字段，是需要額外空間來存放NULL辨別的，是以如果一個char字段中出現非常多的NULL，

那麼很不幸，你的占用空間比沒有NULL的大（但這個大并不是大太多，因為NULL辨別是用bit存放的，

可是如果你一行中隻有你一個NULL需要辨別，那麼你就白白浪費1byte空間了，罪過罪過！），這時候，

你可以使用特殊辨別來存放，如：'NV'

11、同上，是以對于這種NULL查詢，索引是無法生效的，假如你使用了NULL辨別替代的話，那麼恭喜你，

你可以利用到索引了

12、char和varchar的比較成本是一樣的，現在關鍵就看它們的索引查找的成本了，因為查找政策都一樣，

是以應該比較誰占用空間小。在存放相同數量的字元情況下，如果數量小，那麼char占用長度是小于varchar

的，但如果數量稍大，則varchar完全可能小于char，而且要看實際填充數值的充實度，比如說varchar(3)

和char(3)，那麼理論上應該是char快了，但如果是char(10)和varchar(10)，充實度隻有30%的情況下，

理論上就應該是varchar快了。因為varchar需要額外空間存放塊長度，是以隻要length(1-fillfactor)

大于這個存放空間（好像是2位元組)，那麼它就會比相同長度的char快了。

13、nvarchar比varchar要慢上一些，而且對于非unicode字元它會占用雙倍的空間，那麼這麼一種類型

推出來是為什麼呢？對，就是為了國際化，對于unicode類型的資料，排序規則對它們是不起作用的，

而非unicode字元在處理不同語言的資料時，必須指定排序規則才能正常工作，是以n類型就這麼一點好處。

總結陳詞：

1、如果資料量非常大，又能100%确定長度且儲存隻是ansi字元，那麼char

2、能确定長度又不一定是ansi字元或者，那麼用nchar；

3、不确定長度，要查詢且希望利用索引的話，用nvarchar類型吧，将它們設到400；

4、不查詢的話沒什麼好說的，用nvarchar(4000)

5、性格豪爽的可以隻用3和4，偶爾用用1，畢竟這是一種額外說明，等于告訴别人說，我一定需要長度

為X位的資料

本文轉自 netcorner 部落格園部落格，原文連結： http://www.cnblogs.com/netcorner/archive/2007/10/20/2912276.html ，如需轉載請自行聯系原作者