文件首頁
MySQL 8.4 參考手冊
相關文件 下載本手冊
PDF (美式信紙) - 39.9Mb
PDF (A4) - 40.0Mb
Man Pages (TGZ) - 258.5Kb
Man Pages (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 8.4 參考手冊  /  ...  /  CHAR 和 VARCHAR 類型

13.3.2 CHAR 和 VARCHAR 類型

CHARVARCHAR 類型相似,但在儲存和檢索方式上有所不同。它們在最大長度以及是否保留尾隨空格方面也有所不同。

CHARVARCHAR 類型的宣告會使用一個長度,表示您想要儲存的最大字元數。例如,CHAR(30) 可以容納最多 30 個字元。

CHAR 欄位的長度固定為您建立表格時宣告的長度。長度可以是從 0 到 255 的任何值。當儲存 CHAR 值時,它們會使用空格右側填補到指定的長度。當檢索 CHAR 值時,會移除尾隨空格,除非啟用 PAD_CHAR_TO_FULL_LENGTH SQL 模式。

VARCHAR 欄位中的值是可變長度字串。長度可以指定為從 0 到 65,535 的值。VARCHAR 的有效最大長度受最大資料列大小(65,535 位元組,在所有欄位之間共用)和使用的字元集限制。請參閱第 10.4.7 節,〈表格欄位計數和資料列大小的限制〉

CHAR 相反,VARCHAR 值儲存為 1 位元組或 2 位元組的長度前置詞加上資料。長度前置詞表示值中的位元組數。如果值不需要超過 255 位元組,則欄位會使用一個長度位元組;如果值可能需要超過 255 位元組,則使用兩個長度位元組。

如果未啟用嚴格 SQL 模式,並且您將超過欄位最大長度的值指派給 CHARVARCHAR 欄位,則該值會被截斷以符合長度,並產生警告。對於截斷非空格字元,您可以使用嚴格 SQL 模式來導致發生錯誤(而不是警告),並禁止插入該值。請參閱第 7.1.11 節,〈伺服器 SQL 模式〉

對於 VARCHAR 欄位,插入之前會截斷超過欄位長度的尾隨空格,並產生警告,無論使用何種 SQL 模式。對於 CHAR 欄位,無論 SQL 模式如何,都會靜默執行從插入值中截斷多餘尾隨空格的操作。

儲存 VARCHAR 值時不會進行填補。根據標準 SQL,儲存和檢索值時會保留尾隨空格。

下表說明 CHARVARCHAR 之間的差異,方法是顯示將各種字串值儲存到 CHAR(4)VARCHAR(4) 欄位中的結果(假設該欄位使用單一位元組字元集,例如 latin1)。

CHAR(4) 所需儲存空間 VARCHAR(4) 所需儲存空間
'' '    ' 4 位元組 '' 1 位元組
'ab' 'ab  ' 4 位元組 'ab' 3 位元組
'abcd' 'abcd' 4 位元組 'abcd' 5 位元組
'abcdefgh' 'abcd' 4 位元組 'abcd' 5 位元組

表格最後一列中顯示為已儲存的值僅在未使用嚴格 SQL 模式時才適用;如果啟用嚴格模式,則會不儲存超過欄位長度的值,並導致錯誤。

InnoDB 會將長度大於或等於 768 位元組的固定長度欄位編碼為可變長度欄位,這些欄位可以儲存在頁面外。例如,如果字元集的最大位元組長度大於 3(例如 utf8mb4),則 CHAR(255) 欄位可能會超過 768 位元組。

如果將給定的值儲存到 CHAR(4)VARCHAR(4) 欄位中,則從欄位檢索的值並不總是相同的,因為從 CHAR 欄位檢索時會移除尾隨空格。以下範例說明此差異

mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO vc VALUES ('ab  ', 'ab  ');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+
| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
+---------------------+---------------------+
| (ab  )              | (ab)                |
+---------------------+---------------------+
1 row in set (0.06 sec)

CHARVARCHARTEXT 欄位中的值會根據指派給該欄位的字元集校對進行排序和比較。

除了基於 UCA 9.0.0 及更高版本的 Unicode 校對外,MySQL 校對的填補屬性為 PAD SPACE,這些校對的填補屬性為 NO PAD。(請參閱第 12.10.1 節,〈Unicode 字元集〉)。

若要判斷校對的填補屬性,請使用 INFORMATION_SCHEMA COLLATIONS 表格,其具有 PAD_ATTRIBUTE 欄位。

對於非二進位字串(CHARVARCHARTEXT 值),字串排序規則的填充屬性會決定字串結尾的尾隨空格在比較時的處理方式。NO PAD 排序規則會將尾隨空格視為比較中的重要字元,就像任何其他字元一樣。PAD SPACE 排序規則會將尾隨空格視為比較中不重要的字元;字串在比較時會忽略尾隨空格。請參閱比較中尾隨空格的處理。伺服器 SQL 模式對於尾隨空格的比較行為沒有影響。

注意

如需有關 MySQL 字元集和排序規則的詳細資訊,請參閱第 12 章,字元集、排序規則、Unicode。如需有關儲存需求的詳細資訊,請參閱第 13.7 節,「資料類型儲存需求」

在尾隨填充字元被移除或比較忽略它們的情況下,如果某個欄位具有要求唯一值的索引,則將僅尾隨填充字元的數量不同的值插入該欄位會導致重複鍵錯誤。例如,如果表格包含 'a',則嘗試儲存 'a ' 會導致重複鍵錯誤。