MySQL 8.4 發行說明
磁碟上資料表的資料儲存需求取決於幾個因素。不同的儲存引擎以不同的方式表示資料類型和儲存原始資料。資料表資料可能會被壓縮，無論是針對欄位還是整列，這使得計算資料表或欄位的儲存需求變得複雜。
儘管磁碟上的儲存配置不同，但用於溝通和交換資料表列資訊的內部 MySQL API 使用一致的資料結構，適用於所有儲存引擎。
本節包含 MySQL 支援的每個資料類型儲存需求的指南和資訊，包括使用固定大小表示資料類型的儲存引擎的內部格式和大小。資訊依類別或儲存引擎列出。
資料表的內部表示的最大列大小為 65,535 個位元組，即使儲存引擎能夠支援更大的列。此數字不包括 BLOB 或 TEXT 欄位，這些欄位僅佔用 9 到 12 個位元組。對於 BLOB 和 TEXT 資料，資訊在內部儲存在與列緩衝區不同的記憶體區域中。不同的儲存引擎根據它們用於處理相應類型的方法，以不同的方式處理此資料的配置和儲存。有關詳細資訊，請參閱 第 18 章，替代儲存引擎 和 第 10.4.7 節，「資料表欄位計數和列大小限制」。
重要
NDB 資料表使用4 位元組對齊；所有 NDB 資料儲存都以 4 位元組的倍數進行。因此，通常需要 15 個位元組的欄位值在 NDB 資料表中需要 16 個位元組。例如，在 NDB 資料表中，TINYINT、SMALLINT、MEDIUMINT 和 INTEGER (INT) 欄位類型由於對齊因素，每個記錄都需要 4 位元組的儲存空間。
每個 BIT( 欄位佔用 M)M 位元的儲存空間。雖然個別 BIT 欄位不是 4 位元組對齊的，但 NDB 每列會為 BIT 欄位所需的前 1-32 位元保留 4 個位元組（32 位元），然後為 33-64 位元保留另一個 4 個位元組，依此類推。
雖然 NULL 本身不需要任何儲存空間，但如果資料表定義包含任何允許 NULL 的欄位（最多 32 個 NULL 欄位），則 NDB 每列保留 4 個位元組。（如果 NDB Cluster 資料表定義的 NULL 欄位超過 32 個，最多 64 個 NULL 欄位，則每列保留 8 個位元組。）
使用 NDB 儲存引擎的每個資料表都需要一個主鍵；如果您未定義主鍵，NDB 會建立一個「隱藏」主鍵。這個隱藏的主鍵每個資料表記錄會佔用 31-35 個位元組。
您可以使用 ndb_size.pl Perl 指令碼來估算 NDB 儲存需求。它會連線到目前的 MySQL (不是 NDB Cluster) 資料庫，並建立一份報告，說明如果該資料庫使用 NDB 儲存引擎會需要多少空間。有關詳細資訊，請參閱 第 25.5.29 節，「ndb_size.pl — NDBCLUSTER 大小需求估算器」。
| 資料類型 | 所需儲存空間 |
|---|---|
TINYINT |
1 個位元組 |
SMALLINT |
2 個位元組 |
MEDIUMINT |
3 個位元組 |
INT, INTEGER |
4 個位元組 |
BIGINT |
8 個位元組 |
FLOAT( |
如果 0 <= p <= 24，則為 4 個位元組；如果 25 <= p <= 53，則為 8 個位元組 |
FLOAT |
4 個位元組 |
DOUBLE [PRECISION], REAL |
8 個位元組 |
DECIMAL(, NUMERIC( |
各有不同；請參閱以下討論 |
BIT( |
大約 (M+7)/8 個位元組 |
DECIMAL（和 NUMERIC）欄位的值使用二進位格式表示，該格式將九個十進位（以 10 為基數）數字壓縮為四個位元組。每個值的整數和小數部分的儲存空間是分開決定的。九個數字的每個倍數需要四個位元組，而「剩餘」數字則需要四個位元組的某個部分。剩餘數字所需的儲存空間由下表提供。
| 剩餘數字 | 位元組數 |
|---|---|
| 0 | 0 |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 3 |
| 6 | 3 |
| 7 | 4 |
| 8 | 4 |
對於 TIME、DATETIME 和 TIMESTAMP 欄位，在 MySQL 5.6.4 之前建立的資料表與從 5.6.4 或之後建立的資料表所需的儲存空間不同。這是由於 5.6.4 的變更允許這些類型具有小數部分，這需要 0 到 3 個位元組。
| 資料類型 | MySQL 5.6.4 之前的儲存需求 | MySQL 5.6.4 起的儲存需求 |
|---|---|---|
YEAR |
1 個位元組 | 1 個位元組 |
DATE |
3 個位元組 | 3 個位元組 |
TIME |
3 個位元組 | 3 個位元組 + 小數秒儲存空間 |
DATETIME |
8 個位元組 | 5 個位元組 + 小數秒儲存空間 |
TIMESTAMP |
4 個位元組 | 4 個位元組 + 小數秒儲存空間 |
從 MySQL 5.6.4 開始，YEAR 和 DATE 的儲存空間保持不變。然而，TIME、DATETIME 和 TIMESTAMP 的表示方式不同。DATETIME 的封裝效率更高，非小數部分需要 5 而不是 8 個位元組，而且所有三個部分都有一個小數部分，根據儲存值的小數秒精確度，需要 0 到 3 個位元組。
| 小數秒精確度 | 所需儲存空間 |
|---|---|
| 0 | 0 個位元組 |
| 1, 2 | 1 個位元組 |
| 3, 4 | 2 個位元組 |
| 5, 6 | 3 個位元組 |
例如，TIME(0)、TIME(2)、TIME(4) 和 TIME(6) 分別使用 3、4、5 和 6 個位元組。TIME 和 TIME(0) 是等效的，並且需要相同的儲存空間。
有關時間值內部表示的詳細資訊，請參閱 MySQL 內部：重要演算法和結構。
在下表中，M 代表非二進位字串類型的宣告欄位長度（以字元為單位），以及二進位字串類型的宣告欄位長度（以位元組為單位）。L 代表給定字串值的實際長度（以位元組為單位）。
| 資料類型 | 所需儲存空間 |
|---|---|
CHAR( |
InnoDB 列格式的精簡系列針對可變長度字元集優化了儲存。請參閱 COMPACT 列格式儲存特性。否則，M × w 位元組，<= 255，其中 w 是字元集中最大長度字元所需的位元組數。 |
BINARY( |
M 位元組，0 <= 255 |
VARCHAR(、VARBINARY( |
如果欄位值需要 0-255 個位元組，則為 L + 1 個位元組，如果值可能需要超過 255 個位元組，則為 L + 2 個位元組 |
TINYBLOB、TINYTEXT |
L + 1 個位元組，其中 L < 28 |
BLOB、TEXT |
L + 2 個位元組，其中 L < 216 |
MEDIUMBLOB、MEDIUMTEXT |
L + 3 個位元組，其中 L < 224 |
LONGBLOB、LONGTEXT |
L + 4 個位元組，其中 L < 232 |
ENUM(' |
1 或 2 個位元組，取決於列舉值的數量（最多 65,535 個值） |
SET(' |
1、2、3、4 或 8 個位元組，取決於集合成員的數量（最多 64 個成員） |
可變長度字串類型使用長度前綴加上資料儲存。長度前綴需要 1 到 4 個位元組，具體取決於資料類型，前綴的值為 L（字串的位元組長度）。例如，儲存 MEDIUMTEXT 值需要 L 個位元組來儲存值，再加上三個位元組來儲存值的長度。
要計算用於儲存特定 CHAR、VARCHAR 或 TEXT 欄位值的位元組數，您必須考慮該欄位使用的字元集以及該值是否包含多位元組字元。特別是，當使用 UTF-8 Unicode 字元集時，您必須記住並非所有字元都使用相同數量的位元組。utf8mb3 和 utf8mb4 字元集每個字元分別最多需要三個和四個位元組。有關不同類別的 utf8mb3 或 utf8mb4 字元使用的儲存空間的詳細資訊，請參閱 第 12.9 節「Unicode 支援」。
VARCHAR、VARBINARY 和 BLOB 和 TEXT 類型是可變長度類型。對於每個類型，儲存需求取決於以下因素：
欄位值的實際長度
欄位的最大可能長度
用於欄位的字元集，因為某些字元集包含多位元組字元
例如，VARCHAR(255) 欄位可以儲存最大長度為 255 個字元的字串。假設欄位使用 latin1 字元集（每個字元一個位元組），實際需要的儲存空間是字串的長度 (L)，加上一個位元組來記錄字串的長度。對於字串 'abcd'，L 為 4，儲存需求為 5 個位元組。如果改為宣告同一欄位使用 ucs2 雙位元組字元集，則儲存需求為 10 個位元組：'abcd' 的長度為 8 個位元組，而且欄位需要兩個位元組來儲存長度，因為最大長度大於 255（最多 510 個位元組）。
可以儲存在 VARCHAR 或 VARBINARY 欄位中的有效最大 位元組 數受限於 65,535 個位元組的最大列大小，這在所有欄位之間共享。對於儲存多位元組字元的 VARCHAR 欄位，有效最大 字元 數會減少。例如，utf8mb4 字元每個字元最多可能需要四個位元組，因此使用 utf8mb4 字元集的 VARCHAR 欄位可以宣告為最多 16,383 個字元。請參閱 第 10.4.7 節「資料表欄位計數和列大小的限制」。
InnoDB 將長度大於或等於 768 個位元組的固定長度欄位編碼為可變長度欄位，這些欄位可以儲存在頁面之外。例如，如果字元集的最大位元組長度大於 3，則 CHAR(255) 欄位可能會超過 768 個位元組，就像 utf8mb4 的情況一樣。
NDB 儲存引擎支援可變寬度欄位。這表示 NDB Cluster 資料表中的 VARCHAR 欄位與任何其他儲存引擎所需的儲存空間相同，但這些值是 4 位元組對齊的除外。因此，使用 latin1 字元集儲存在 VARCHAR(50) 欄位中的字串 'abcd' 需要 8 個位元組（而不是 MyISAM 資料表中相同欄位值的 5 個位元組）。
TEXT、BLOB 和 JSON 欄位在 NDB 儲存引擎中的實作方式不同，其中欄中的每一列都由兩個獨立的部分組成。其中一個是固定大小的（TEXT 和 BLOB 為 256 個位元組，JSON 為 4000 個位元組），實際上儲存在原始資料表中。另一個部分由任何超過 256 個位元組的資料組成，這些資料儲存在隱藏的 blob 部分資料表中。第二個資料表中列的大小由欄位的確切類型決定，如下表所示：
| 類型 | BLOB 部分大小 |
|---|---|
BLOB、TEXT |
2000 |
MEDIUMBLOB、MEDIUMTEXT |
4000 |
LONGBLOB、LONGTEXT |
13948 |
JSON |
8100 |
這表示如果 size <= 256 (其中 size 代表列的大小)，則 TEXT 欄位的大小為 256；否則，大小為 256 + size + (2000 × (size − 256) % 2000)。
NDB 不會為 TINYBLOB 或 TINYTEXT 欄位值單獨儲存 blob 部分。
您可以使用建立或變更父表格時，在欄位註解中使用 NDB_COLUMN，將 NDB blob 欄位的 blob 部分大小增加到最大值 13948。NDB 也支援使用欄位註解中的 NDB_TABLE 設定 TEXT、BLOB 或 JSON 欄位的內嵌大小。請參閱 NDB_COLUMN 選項，以取得更多資訊。
ENUM 物件的大小由不同的列舉值數量決定。對於最多有 255 個可能值的列舉，使用一個位元組。對於有 256 到 65,535 個可能值的列舉，則使用兩個位元組。請參閱 第 13.3.5 節，「ENUM 類型」。
SET 物件的大小由不同的集合成員數量決定。如果集合大小為 N，則物件會佔用 ( 個位元組，向上捨入為 1、2、3、4 或 8 個位元組。N+7)/8SET 最多可以有 64 個成員。請參閱 第 13.3.6 節，「SET 類型」。
MySQL 使用 4 個位元組來指示 SRID，後面接著值的 WKB 表示法，來儲存幾何值。LENGTH() 函數會傳回儲存值所需的空間 (以位元組為單位)。
如需空間值的 WKB 和內部儲存格式的說明，請參閱 第 13.4.3 節，「支援的空間資料格式」。
一般而言，JSON 欄位的儲存需求與 LONGBLOB 或 LONGTEXT 欄位大致相同；也就是說，JSON 文件消耗的空間與將文件的字串表示形式儲存在這些類型的欄位之一中大致相同。但是，二進位編碼會產生一些額外負擔，包括儲存在 JSON 文件中個別值所需的元資料和查詢字典。例如，根據字串的長度和儲存字串的物件或陣列的大小，儲存在 JSON 文件中的字串需要額外 4 到 10 個位元組的儲存空間。
此外，MySQL 對儲存在 JSON 欄位中的任何 JSON 文件的大小設定了限制，使其不得大於 max_allowed_packet 的值。