2012年1月3日 星期二

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

引用:
--
資料庫定義到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位元的數據。

沒有留言:

張貼留言