ms sql數據庫裏char、varchar、text和nchar、nvarchar、ntext的區別

轉自：夢仙士 http://blog.sina.com.cn/s/blog_724cf46101011hvi.html

char、varchar、text和nchar、nvarchar、ntext的區別
varchar在SQL Server中是採用單字節來存儲數據的，nvarchar是使用Unicode來存儲數據的．中文字符存儲到SQL
Server中會保存爲兩個字節（通常採用Unico編碼），英文字符保存到數據庫中，若是字段的類型爲varchar，則只會佔用一個字節，而若是字段的類型爲nvarchar，則會佔用兩個字節．
　　正常狀況下，咱們使用varchar也能夠存儲中文字符，可是若是遇到操做系統是英文操做系統而且對中文字體的支持不全面時, 在SQL
Server存儲中文字符爲varchar就會出現亂碼(顯示爲??)．並且正常狀況下，主機都會支持中文的環境，因此若是使用varchar來存儲數據，在開發階段是發現不了的．多數狀況下，在佈署的時候也不會有問題．
　　可是！若是佈署的主機是英文操做系統，而且不支持中文環境，那問題就出來了．全部的varchar字段在存儲中文的時候都會變成亂碼（顯示爲??）．並且通常狀況下你不會知道這是由於你採用了錯誤的數據類型來存儲所形成的，你會試着去裝中文字體，試着去設置操做系統的語言環境．．．這些都不能解決問題，惟一能解決問題的是把數據庫字段的類型個性爲nvarchar（或者nchar）．對項目管理比較熟悉的朋友應該都知道，到佈署階段再來修改數據庫是一個很恐怖的事情．
　　使用nvarchar的另外一個很是好處就是在判斷字符串的時候能夠不須要考慮中英文兩種字符的差異．
　　固然，使用nvarchar存儲英文字符會增大一倍的存儲空間．可是在存儲代價已經很低廉的狀況下，優先考慮兼容性會給你帶來更多好處的．
　　因此在Design的時候應該儘可能使用nvarchar來存儲數據．只有在你確保該字段不會保存中文的時候，才採用varchar來存儲．------------------------------
一、 varchar： 可變長度的非
Unicode
數據，最長爲
8,000
個字符。
2、nvarchar：
可變長度 Unicode
數據，其最大長度爲
4,000
字符。
3、char:
固定長度的非 Unicode
字符數據，最大長度爲
8,000
個字符。
4、nchar
固定長度的
Unicode
數據，最大長度爲
4,000
個字符。
5、
char和varchar都是字符串類型的 用Unicode編碼的字符串,結果是字符的整數值.
有時中文也能夠考慮VARCHAR，畢竟有時候在前臺語言處理字符長度好一些，權衡來看，unicode本身抉擇，推薦使用NVARCHAR。=======================================================若是
varchar(300)
和 varchar(8000)
都存儲相同的字符數，性能上是沒有差異的，存儲行爲上也沒有不一樣。由於它們都有相同的存儲結構，兩個字節的偏移，兩個字節的列數（若是表中全部的列都是 varchar
類型）。區別只在於存儲容量上。 大多數的性能比較都集中在
varchar
和
char，varchar
和
varchar(max)
上。還有，行外存儲（SQL Server 2005
支持的）。 　　varchar(max)
（）與 varchar
存儲方式是不一樣的。 　　當 LOB 數據足夠小時，能夠考慮將數據直接存儲在數據行（行所在的數據頁面）中，從而能夠避免額外的讀取 LOB
頁面，提高訪問 LOB 數據的效率（將 LOB 數據直接存儲在數據頁面的閾值由 text
in
row 選項設置）。 而當 LOB 數據大於此閾值，或者所在行的大小超過了
8060
字節（單行最大 SIZE），LOB 數據將會存儲在 LOB 頁面，而在數據頁面中保留一個指向 LOB 頁面的
16
字節的指針。其訪問效率固然會將低。 另外還有，惡意用戶能夠利用這一點「撐爆」你的磁盤。
======================
text最好不用,只適於存儲大數據,還要用專門的函數來讀寫更新,麻煩
1.text能不用就不用
2.ntext
等，不須要就不用
3.char比varchar效率高一些(請高人判斷一下這句是否正確)
4.text呢？效率比別兩種慢不慢？除了存地數據多以外，還有沒有別的優點？
文本型數據中你能夠存儲超過20億個字符串，怎麼樣，這個夠大了吧？可是也不是任什麼時候候都是和使用文本型數據，由於他很是佔空間，也很是消耗服務器，隨處亂用後果不堪設想！由於即便你像一個文本型字段輸入了一個空值他都會佔用2K的空間！而當這時除了刪除該數據沒有別的辦法收回空間！效率不高這個能夠確定
不能比較或排序 text、ntext
和
image
數據類型 最近在開發一個文件管理系統的時候，遇到一個問題：原本偶在本地的數據庫是SQL2008，有一個字段SharedUserId
是nvarchar(max)類型，偶在查詢SQL語句中用了...AND
SharedUserId
<>
''，
能夠正常執行。後來把程序發佈到買的空間服務器上，服務器上是SQL2000的數據庫，由於SQL2000沒有nvarchar(max)類型，因此偶改爲了text類型，結果在執行一樣的SQL語句時程序就報錯了:
MySQL和MSSQL下，text
、ntext、
image、blob的比較
sm_crystal /
2011-09-28
/
字體大小選擇：
1、MySQL存在text和blob：
(1)、相同
在TEXT或BLOB列的存儲或檢索過程當中，不存在大小寫轉換,當未運行在嚴格模式時，若是你爲BLOB或TEXT列分配一個超過該列類型的最大長度的值值，值被截取以保證適合。若是截掉的字符不是空格，將會產生一條警告。使用嚴格SQL模式，會產生錯誤，而且值將被拒絕而不是截取並給出警告。
BLOB和TEXT列不能有默認值。
當保存或檢索BLOB和TEXT列的值時不刪除尾部空格。(這與VARBINARY和VARCHAR列相同）。
對於BLOB和TEXT列的索引，必須指定索引前綴的長度。對於CHAR和VARCHAR，前綴長度是可選的。
(2)、相異
text
: TEXT值是大小寫不敏感的 Text被視爲非二進制字符串 TEXT列有一個字符集，而且根據字符集的 校對規則對值進行排序和比較
能夠將TEXT列視爲VARCHAR列 MySQL鏈接程序/ODBC將TEXT值定義爲LONGVARCHAR
BLOB
能夠儲存圖片,TEXT不行，TEXT只能儲存純文本文件。4個TEXT類型TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT對應於4個BLOB類型，而且有一樣的最大長度和存儲需求。
blob: BLOB值的排序和比較以大小寫敏感方式執行; BLOB被視爲二進制字符串;
BLOB列沒有字符集，而且排序和比較基於列值字節的數值值。 在大多數方面，能夠將BLOB列視爲可以足夠大的VARBINARY列
MySQL鏈接程序/ODBC將BLOB值定義爲LONGVARBINARY
一個BLOB是一個能保存可變數量的數據的二進制的大對象。4個BLOB類型TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB僅僅在他們能保存值的最大長度方面有所不一樣。
(3)其餘：
VARCHAR，BLOB和TEXT類型是變長類型，對於其存儲需求取決於列值的實際長度(在前面的表格中用L表示)，而不是取決於類型的最大可能尺寸。例如，一個VARCHAR(10)列能保存最大長度爲10個字符的一個字符串，實際的存儲須要是字符串的長度
，加上1個字節以記錄字符串的長度。對於字符串'abcd'，L是4而存儲要求是5個字節。
BLOB和TEXT類型須要1，2，3或4個字節來記錄列值的長度，這取決於類型的最大可能長度。VARCHAR須要定義大小，有255的最大限制；TEXT則不須要。若是你把一個超過列類型最大長度的值賦給一個BLOB或TEXT列，值被截斷以適合它。
CHAR(n)
固定長度，最多 255
個字符
VARCHAR(n)
可變長度，MySQL 4.1
及之前最大
255
字符，MySQL
5
以後最大
65535
字節 TINYTEXT 可變長度，最多
255
個字符
TEXT
可變長度，最多
65535
個字符 MEDIUMTEXT 可變長度，最多
16777215（2^24
-
1）個字符
LONGTEXT 可變長度，最多 4294967295（2^32
-
1）（4G）個字符
2、MSSQL存在text、ntext和image：
ntext：
可變長度 Unicode
數據的最大長度爲
2^30
-
1
(1,073,741,823)
個字符。存儲大小是所輸入字符個數的兩倍（以字節爲單位）。ntext
在 SQL-92
中的同義詞是
national
text。
text：
服務器代碼頁中的可變長度非 Unicode
數據的最大長度爲
2^31-1
(2,147,483,647)
個字符。當服務器代碼頁使用雙字節字符時，存儲量還是 2,147,483,647
字節。存儲大小可能小於
2,147,483,647
字節（取決於字符串）。
image：
在 Image
數據類型中存儲的數據是以位字符串存儲的，不是由 SQL Server 解釋的，必須由應用程序來解釋。例如，應用程序可使用
BMP、TIEF、GIF 和 JPEG 格式把數據存儲在 Image
數據類型中。