轉(zhuǎn)： http://blog.csdn.net/jackychu/article/details/4183118

http://www.cnblogs.com/jhxk/articles/1633578.html

很多開(kāi)發(fā)者進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候往往并沒(méi)有太多的考慮char， varchar類型，有的是根本就沒(méi)注意，因?yàn)榇鎯?chǔ)價(jià)格變得越來(lái)越便宜了，忘記了最開(kāi)始的一些基本設(shè)計(jì)理論和原則，這點(diǎn)讓我想到了現(xiàn)在的年輕人，大手一揮 一把人民幣就從他手里溜走了，其實(shí)我想不管是做人也好，做開(kāi)發(fā)也好，細(xì)節(jié)的把握直接決定很多東西。當(dāng)然還有一部分人是根本就沒(méi)弄清楚他們的區(qū)別，也就隨便 選一個(gè)。在這里我想對(duì)他們做個(gè)簡(jiǎn)單的分析，當(dāng)然如果有不對(duì)的地方希望大家指教。

1、 CHAR 。CHAR存儲(chǔ)定長(zhǎng)數(shù)據(jù)很方便，CHAR字段上的索引效率級(jí)高，比如定義char(10)，那么不論你存儲(chǔ)的數(shù)據(jù)是否達(dá)到了10個(gè)字節(jié)，都要占去10個(gè)字節(jié)的空間,不足的自動(dòng)用空格填充，所以 在讀取的時(shí)候可能要多次用到trim（）。

2、 VARCHAR 。存儲(chǔ)變長(zhǎng)數(shù)據(jù)，但存儲(chǔ)效率沒(méi)有CHAR高。如果一個(gè)字段可能的值是不固定長(zhǎng)度的，我們只知道它不可能超過(guò)10個(gè)字符，把它定義為 VARCHAR(10)是最合算的。VARCHAR類型的實(shí)際長(zhǎng)度是它的值的實(shí)際長(zhǎng)度+1。為什么“+1”呢？這一個(gè)字節(jié)用于保存實(shí)際使用了多大的長(zhǎng)度。 從空間上考慮，用varchar合適；從效率上考慮，用char合適，關(guān)鍵是根據(jù)實(shí)際情況找到權(quán)衡點(diǎn)。

3、 TEXT 。text存儲(chǔ)可變長(zhǎng)度的非Unicode數(shù)據(jù)，最大長(zhǎng)度為2^31-1(2,147,483,647)個(gè)字符。

4、 NCHAR、NVARCHAR、NTEXT 。這三種從名字上看比前面三種多了個(gè)“N”。它 表示存儲(chǔ)的是Unicode數(shù)據(jù)類型的字符 。我們知道字符中，英 文字符只需要一個(gè)字節(jié)存儲(chǔ)就足夠了，但漢字眾多，需要兩個(gè)字節(jié)存儲(chǔ)，英文與漢字同時(shí)存在時(shí)容易造成混亂，Unicode字符集就是為了解決字符集這種不兼 容的問(wèn)題而產(chǎn)生的，它所有的字符都用兩個(gè)字節(jié)表示，即英文字符也是用兩個(gè)字節(jié)表示。nchar、nvarchar的長(zhǎng)度是在1到4000之間。和 char、varchar比較起來(lái)，nchar、nvarchar則最多存儲(chǔ)4000個(gè)字符，不論是英文還是漢字；而char、varchar最多能存儲(chǔ) 8000個(gè)英文，4000個(gè)漢字。可以看出 使用nchar、nvarchar數(shù)據(jù)類型時(shí)不用擔(dān)心輸入的字符是英文還是漢字，較為方便，但在存儲(chǔ)英文時(shí)數(shù)量 上有些損失。

所以一般來(lái)說(shuō)，如果含有中文字符，用nchar/nvarchar，如果純英文和數(shù)字，用char/varcha r

我把他們的區(qū)別概括成：

CHAR，NCHAR 定長(zhǎng)，速度快，占空間大，需處理
VARCHAR，NVARCHAR，TEXT 不定長(zhǎng)，空間小，速度慢，無(wú)需處理
NCHAR、NVARCHAR、NTEXT處理Unicode碼

第二篇：

以前只知道text和image是可能被SQL Server淘汰的數(shù)據(jù)類型，但具體原因不太清楚，今天讀書(shū)的時(shí)候發(fā)現(xiàn)了text與varchar(max)和nvarchar(max)的區(qū)別，主要是對(duì)操作符的限制，text只能被下列函數(shù)作用：

?

函數(shù)	語(yǔ)句
DATALENGTH	READTEXT
PATINDEX	SET TEXTSIZE
SUBSTRING	UPDATETEXT
TEXTPTR	WRITETEXT
TEXTVALID	?

?

舉個(gè)列子，如果“文本”這一列的數(shù)據(jù)類型為text，那么它將不能用于“=”“l(fā)eft()”等操作，比如下面的例子：

建立表，填充數(shù)據(jù)：

if exists ( select * from sysobjects where id = OBJECT_ID ( '[asdf]' ) and OBJECTPROPERTY (id, 'IsUserTable' ) = 1)

DROP TABLE [asdf]

CREATE TABLE [asdf] (

[inttest] [int] IDENTITY (1, 1) NOT NULL ,

[text] [text] NULL ,

[varcharmax]?varchar(max) NULL )

ALTER TABLE [asdf] WITH NOCHECK ADD CONSTRAINT [PK_asdf] PRIMARY KEY NONCLUSTERED ( [inttest] )

SET IDENTITY_INSERT [asdf] ON

INSERT [asdf] ( [inttest] , [text] , [varcharmax] ) VALUES ( 1 , '1111111' , '1111111' )

SET IDENTITY_INSERT [asdf] OFF

運(yùn)行查詢：

查詢一：
SELECT [text]

????? ,[varcharmax]

FROM [testDB].[dbo].[asdf]

where

[text] = '11111' AND

[varcharmax] = '1111111'

會(huì)出現(xiàn)以下錯(cuò)誤提示：

消息402，級(jí)別16，狀態(tài)1，第1 行

數(shù)據(jù)類型text 和varchar 在equal to 運(yùn)算符中不兼容。

查詢二 ：
SELECT [text]

????? ,[varcharmax]

FROM [testDB].[dbo].[asdf]

where

[varcharmax] = '1111111'

可以成功運(yùn)行

在MS SQL2005及以上的版本中，加入大值數(shù)據(jù)類型（varchar(max)、nvarchar(max)、varbinary(max) ）。大值數(shù)據(jù)類型最多可以存儲(chǔ)2^30-1個(gè)字節(jié)的數(shù)據(jù)。

這幾個(gè)數(shù)據(jù)類型在行為上和較小的數(shù)據(jù)類型 varchar 、 nvarchar 和 varbinary 相同。

微軟的說(shuō)法是用這個(gè)數(shù)據(jù)類型來(lái)代替之前的 text 、 ntext 和 image 數(shù)據(jù)類型，它們之間的對(duì)應(yīng)關(guān)系為：

varchar(max)-------text;

nvarchar(max)-----ntext;

varbinary(max)----image.

?

有了大值數(shù)據(jù)類型之后，在對(duì)大值數(shù)據(jù)操作的時(shí)候要比以前靈活的多了。比如：之前text是不能用‘like’的，有了varchar(max)之后 就沒(méi)有這些問(wèn)題了，因?yàn)関archar(max)在行為上和varchar(n)上相同，所以，可以用在varcahr的都可以用在 varchar(max)上。

另外，這個(gè)還支持對(duì) 插入的 和 刪除的 表中的大值數(shù)據(jù)類型列引用上使用 AFTER 觸發(fā)器。text就不行，總之，用了大值數(shù)據(jù)類型之后，我是“腰也不疼了，腿也不酸了，一口氣也能上六樓了”。還等什么呢，快用大值類型吧。

---

2014年10月16日11:34:19

對(duì)SQL Server數(shù)據(jù)庫(kù)的數(shù)據(jù)類型存儲(chǔ)的學(xué)習(xí)掌握的確實(shí)不太好，我覺(jué)得我以前就是作者說(shuō)的現(xiàn)在的年輕人，看了一點(diǎn)資料，對(duì)作者說(shuō)的進(jìn)行一下總結(jié)：

1.數(shù)據(jù)類型的對(duì)應(yīng)關(guān)系：

varchar(max)-------text;

nvarchar(max)-----ntext;

varbinary(max)----image.

2.現(xiàn)在盡量不用text,ntext,image類型來(lái)存儲(chǔ)數(shù)據(jù)了

3.從空間上考慮，用varchar合適（其實(shí)還是盡量使用varchar,畢竟現(xiàn)在是大數(shù)據(jù)時(shí)代）；從效率上考慮，用char合適，關(guān)鍵是根據(jù)實(shí)際情況找到權(quán)衡點(diǎn)。

4.使用nchar、nvarchar數(shù)據(jù)類型時(shí)不用擔(dān)心輸入的字符是英文還是漢字，較為方便，但在存儲(chǔ)英文時(shí)數(shù)量上有些損失。所以一般來(lái)說(shuō)，如果含有中文字符，用nchar/nvarchar，如果純英文和數(shù)字，用char/varchar

5.

支持多語(yǔ)言的站點(diǎn)應(yīng)考慮使用 Unicode nchar 或 nvarchar 數(shù)據(jù)類型以盡量減少字符轉(zhuǎn)換問(wèn)題。

如果希望列中的數(shù)據(jù)值大小接近一致，請(qǐng)使用 char。

如果希望列中的數(shù)據(jù)值大小顯著不同，請(qǐng)使用 varchar。

如果希望列中所有數(shù)據(jù)項(xiàng)的大小接近一致，則使用 nchar。

如果希望列中數(shù)據(jù)項(xiàng)的大小差異很大，則使用 nvarchar。

如果執(zhí)行 CREATE TABLE 或 ALTER TABLE 時(shí) SET ANSI_PADDING 為 OFF，則一個(gè)定義為 NULL 的 char 列將被作為 varchar 處理。

6.

1）如果數(shù)據(jù)量非常大，又能100%確定長(zhǎng)度且保存只是ansi字符，那么char
2）能確定長(zhǎng)度又不一定是ansi字符或者，那么用nchar；
3）不確定長(zhǎng)度，要查詢且希望利用索引的話，用nvarchar類型吧，將它們?cè)O(shè)到400；
4）不查詢的話沒(méi)什么好說(shuō)的，用nvarchar(4000)

7.

CHAR，NCHAR 定長(zhǎng)，速度快，占空間大，需處理
VARCHAR，NVARCHAR，TEXT 不定長(zhǎng)，空間小，速度慢，無(wú)需處理
NCHAR、NVARCHAR、NTEXT處理Unicode碼

?

SQL Server中char、varchar、text和nchar、nvarchar、ntext的區(qū)別