事情開始得很簡單。MegaWare公司市場部門想要一個（gè）新的網站來發布文檔，開發團隊覺得使用SQL Server 2000數（shù）據庫作為（wéi）文檔存儲倉庫會使事情變（biàn）得簡單。Steve是MegaWare的數據庫管（guǎn）理員，沒（méi）有看出這有什麽大問題;在數據庫中存儲文檔，而不是使用文件係統（tǒng），意味著服務（wù）器需要多（duō）做一些工作，但（dàn）是它也（yě）會使得備份和管理容易得（dé）多。數據（jù）庫與文件係統變得不同步也應該是不可能（néng）的（de）。

市場部門想要存儲的許多文檔都超過了8000個字節，那麽很明顯VARCHAR不是適合這項工作的數據類型。作為替代，TEXT數據類型被用（yòng）來定義存（cún）放數據的字段。因為每個TEXT都能容納2GB的內容，TEXT要存（cún）放市場部門的同事們扔進數據庫的最大的文件也是沒有問題的。

數（shù）月過（guò）去了，市場用大量的無聊拷（kǎo）貝（bèi）填滿了整個數據庫。但是這還不是Steve真正關心的問題。數據庫愉快地嗡嗡作響地運轉著，每個人對項目的結果都很滿意。

直到公司（sī）的標語改變的那個重大的日子。市場部的團隊認為（wéi）“MegaWare: It's really cool!”要比原來的“It's MegaWare's Way or the Highway!” 聽起來更好。因為市場部團隊已經將原來的標語嵌入了倉庫中每（měi）個文檔（dàng）的頁腳上，現在Steve的（de）工作就是更（gèng）改所有這些文檔的頁腳（jiǎo）。

“沒有問題，” Steve想，打開SQL Server 查（chá）詢分析器工具（jù），執（zhí）行了如下的（de）T-SQL批處理:

UPDATE MarketingDocuments

SET Document =

REPLACE(Document,

'It''s MegaWare''s Way or the Highway!',

'MegaWare: It''s really cool!)

當他看到出現的錯誤消息的（de）時候，Steve的輕鬆的微笑很快消失了，“替換函數的參數1，text數據類型無效（xiào）。”

替換函數在編（biān）寫出來的時候，就對TEXT數據類型不（bú）起作用（yòng）。同樣也對CHARINDEX或者SUBSTRING不起作用——或者至（zhì）少是他們在超（chāo）過8千（qiān）個字符的情況下不起作用。更進一步地（dì）講，開發人（rén）員（yuán）忘了處理TEXT或者IMAGE類型的本地變量;實（shí）際上不支持（chí）任何（hé）操作。即使是簡（jiǎn）單（dān）地更新一個文（wén）檔中的一個子字符（fú）串都需要用到晦澀的東西，以及難以使用的類似READTEXT和WRITETEXT的函數。而不是開發人員或者忙（máng）碌（lù）的數據庫管理員因（yīn）為（wéi）想要弄清如何正確使用而采（cǎi）用了不同類型的函數（shù）消耗了時間。

SQL Server的開發人員很幸運，他們將會撥開烏（wū）雲見藍天（tiān）。SQL Server 2005引入了一係列新的被稱為MAX的數據類型。這（zhè）是VARCHAR，NVARCHAR和VARBINARY類型的擴展（zhǎn），這幾種類型以前被限製在（zài）8000字節以下。MAX可以容納高達2GB的數據，與（yǔ）TEXT和IMAGE一樣——並且完全兼容所有的SQL Server內置的字符串函數。

用MAX關（guān）鍵字定義一個某種MAX類型的變量與替代字符串的尺寸(為（wéi）VARCHAR/NVARCHAR的時候)或者字節(為VARBINARY的時候)一樣簡單。

DECLARE @BigString VARCHAR(MAX)

SET @BigString = 'abc'

雖（suī）然這個變量可以自由地操縱，並且可以傳遞給任何的內置的字符串函數，兼容性仍然（rán）不是沒有問題。首先，開發人員不能（néng）期望指定（dìng）了尺寸的VARCHAR和VARBINARY變量在達到8000個字節的極限的時候（hòu）可（kě）以自（zì）動“升級”到MAX版（bǎn）本。例如，如下（xià）的（de）批處理:

DECLARE @String1 VARCHAR(4001)

DECLARE @String2 VARCHAR(4001)

SET @String1 = REPLICATE('1', 4001)

SET @String2 = REPLICATE('2', 4001)

SELECT LEN(@String1 + @String2)

4001+4001=8002，但是指定（dìng）了尺寸的VARCHAR的極限是8000。因為這兩個變量中沒有一個（gè）是MAX類（lèi）型，LEN函數（shù）的結果就是（shì）8000，不是8002。在將兩個變量連接的時候，一種簡單的修正方法就是聲明這兩個變量（liàng）中的一個為VARCHAR(MAX)或者將其中的一個（gè）變量進行轉換。與一個（gè）規定了尺寸的類型進行連接（jiē）的時候（hòu），優先考慮MAX類型，最終結果是MAX類型。所以，以下（xià）批處理（lǐ）的（de）結果是8002，正如我（wǒ）們期望的一樣:

DECLARE @String1 VARCHAR(4001)

DECLARE @String2 VARCHAR(4001)

SET @String1 = REPLICATE('1', 4001)

SET @String2 = REPLICATE('2', 4001)

SELECT LEN(CONVERT(VARCHAR(MAX), @String1) + @String2)

在傳遞給字符串函數的（de）時（shí）候，開發人員意識到字符串的原意在默（mò）認（rèn）情況下是（shì）規定了尺寸的，而不是MAX類型，也是至關重要的。例如，以下查詢的結果（guǒ）就很令人驚奇:

SELECT LEN(REPLICATE('1', 8002))

因為（wéi）字符串‘1’是被作為（wéi）規定了尺寸的VARCHAR對待，而不是VARCHAR(MAX)，結果就是8000——但是在SQL Server 2005中，REPLICATE函數能夠產生高達2GB的字符串。要修正這個問題，可以將字符串（chuàn）轉換為VARCHAR(MAX)，這樣函數就會（huì）輸出同（tóng）樣的類型了:

SELECT LEN(REPLICATE(CONVERT(VARCHAR(MAX), '1'), 8002))

這個查（chá）詢（xún）現在將會返回期望的結果:8002。記住，總是要對采用了新特（tè）性（xìng）編寫（xiě）的代碼進行非常仔細的測試;隱藏的（de）問題，例如上麵描述（shù）的問題，可能並且毫無疑問地會在最壞的時間裏造成災難性的後果。

除了變（biàn）量之外，MAX類型也可以用於定義表的字段（duàn）:

CREATE TABLE BigStrings

(

BigString VARCHAR(MAX)

)

當用於表的時候，意識（shí）到MAX類型（xíng）具有與TEXT和IMAGE類型稍微不同的行溢（yì）出行為是非常重要的。在SQL Server中，最大的行尺寸是8060字節。要（yào）超過這個限製，並且仍然管理每個都擁有高達2GB的存（cún）儲，用TEXT和（hé）IMAGE類型存儲的數據會被存儲引擎自（zì）動地斷行，在行裏隻留下一個16字節的指針。這意味著行的尺寸是減少了，這對性（xìng）能有好處。然而（ér），檢索大數據是（shì）昂貴的，因為它不是與同一行的數據存放在同一（yī）個（gè）位置（zhì）。

MAX數據類型在（zài）默認情況下（xià），使用TEXT/IMAGE溢出（chū）行（háng）為（wéi）和（hé）正常尺寸的VARCHAR/VARBINARY類型（xíng）的行為的混合方式。如（rú）果一個字段的數據，加上表中所有（yǒu）其他（tā）字段的數據，總量少於8060字節，數據就存放在行內。如果（guǒ）數據超過8060字節，MAX字段的數（shù）據就會存放在行外。對於大字符串的表，以下的行將會與表中的其他數據存儲在同一個數據頁內:

INSERT BigStrings (BigString)

VALUES (REPLICATE('1', 8000))

But the following row will result in an overflow:

INSERT BigStrings (BigString)

VALUES (REPLICATE(CONVERT(VARCHAR(MAX), '1'), 100000))

你（nǐ）可以更改（gǎi）MAX數（shù）據類（lèi）型在每個表的基礎上的默認的行（háng）為（wéi），它們會表現得和TEXT和IMAGE類（lèi）型一樣。這是通過使用（yòng）sp_tableoption 存儲過程（chéng）中的“大數值（zhí）類型在行外”選項實現的。為了修（xiū）改大字符串表以將MAX類型的處理方式變得與TEXT和IMAGE數據類型的處理方式相同，可以使用如（rú）下的T-SQL:

EXEC sp_tableoption

'BigStrings',

'large value types out of row',

'1'

看看定義一個MAX數據類型有多容易，與他們提供的靈活性一樣，一些數據設計師將會被引誘以下列的方式開始定義表（biǎo）:

CREATE TABLE Addresses

(

Name VARCHAR(MAX),

AddressLine1 VARCHAR(MAX),

AddressLine2 VARCHAR(MAX),

City VARCHAR(MAX),

State VARCHAR(MAX),

PostalCode VARCHAR(MAX)

)

設計師要注意了:不要這樣做!一個企業中的數據模型既應該包（bāo）含有具有實際限製的數據，還要給用戶接口設計師有關字段（duàn）尺寸的大致的（de）指導。像這樣的表又該創建什麽樣的用（yòng）戶接口（kǒu）呢?

除了數據整（zhěng）合和用戶接口含義之（zhī）外，如果設計師這樣不必要地使用這些類型還會帶來性能上的（de）損害。記住，查詢優化器使用字（zì）段的（de）尺寸作為判斷優化查詢計（jì）劃的眾多標準之一。對於這個表，優化器幾乎沒有（yǒu）任何選擇。

所（suǒ）以，現（xiàn）在你知道了MAX數據類型為SQL Server 2005處理（lǐ）大數據增加了很大部分的（de）靈活性（xìng）。但是MegaWare的那個不幸的數（shù）據庫管理員，Steve會發生什麽變化?還在堅持使用SQL Server 2000，他開始更（gèng）新簡曆，想象著如果更新（xīn）表失（shī）敗了話，他的工作（zuò）也就失去了。但是他也是幸運的——還有世界各地的MegaWare產品的擁護者——用GOOGLE的（de）搜索可以很快地找到這篇文章《在TEXT字段中查找並（bìng）替代》，這篇文章告訴他如何正確的進行（háng）更新。他花了整晚的時間來學習資料;再過幾個月之後，TEXT和IMAGE數據類（lèi）型就僅僅是一段不愉（yú）快的（de）記憶了。