MySQL和MSSQL下，text 、Ntext、 image、blob的比較

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 資料類型中。