Article Directory
Official document address: 11.7 Data Type Storage Requirements
The storage requirements for table data on disk depend on several factors. Different storage engines indicate that data types store raw data in different ways. For a column or the entire row, the table data may be compressed, which makes the calculation of the storage requirements of the table or column more complicated.
Although the storage layout on disk is different, the internal MySQL APIs use a consistent data structure to communicate and exchange information about table rows, and are applicable to all storage engines.
This section includes guidelines and information on storage requirements for each data type supported by MySQL, including the internal format and size of storage engines that use fixed sizes to represent data types. Information is listed by category or storage engine.
The maximum row size of the internal representation of a table is 65,535bytes, even if the storage engine can support larger rows. This number excludes BLOBor TEXTcolumns, which only occupy up 9to 12a byte of this size . For BLOBsum TEXTdata, the information is stored in a memory area different from the line buffer. Different storage engines deal with the distribution and storage of these data in different ways according to their processing methods of corresponding types. For more information, see Chapter 16, you can choose the storage engine and 8.4.7 to limit the number of columns and rows on the table size .
InnoDB table storage requirements
For InnoDBtable storage requirements, see 15.10 InnoDB Row Format .
NDB table storage requirements
Important
NDBtables use4byte alignment; allNDBdata storage is4a multiple of bytes. Therefore,15a column value that usually requires one byte requires one byte in theNDBtable16. For example, in theNDBtable, due to alignment of factors,TINYINT,SMALLINT,MEDIUMINTandINTEGER(INT) are required for each record type column4bytes of storage.
EachBIT(M)column occupies aMbit storage space. Although a singleBITcolumn is not4byte-aligned, butNDBisBITrequired before the column1-32reserved bit per row4bytes (32bits), and then to33-64bits reserved Further4bytes, as an example.
AlthoughNULLit does not require any storage space itself, if the table definition containsNULLany columns thatNDBare allowed to be , it will reserve4bytes for each row , up to32aNULLcolumn. (If aNDB Clustertable defines more than32oneNULLcolumn, the maximum number64ofNULLcolumns, then each row reserves8one byte.)
Every NDBtable that uses a storage engine needs a primary key; if you do not define a primary key, NDBa "hidden" primary key will be created. This hidden primary key consumes 31-35bytes per table record .
You can use ndb_size.plPerl scripts to estimate NDBstorage requirements. It connects to the current MySQL (not NDB Cluster) database and creates a report showing NDBhow much space the database needs if the storage engine is used . For more information, see 23.4.28 ndb_size.pl-NDBCLUSTER size storage estimator .
Numerical storage requirements
| type of data | Storage requirements |
|---|---|
TINYINT |
1 byte |
SMALLINT |
2 bytes |
MEDIUMINT |
3 bytes |
INT, INTEGER |
4 bytes |
BIGINT |
8 bytes |
FLOAT(p) |
If 0 <= p <= 24, 4 bytes If 25 <= p <= 53, 8 bytes |
FLOAT |
4 bytes |
DOUBLE [PRECISION], REAL |
8 bytes |
DECIMAL(M,D), NUMERIC(M,D) |
Changes, see the discussion below |
BIT(M) |
Approximately (M+7)/8 bytes |
DECIMAL(And NUMERICvalues) column using a binary format, which format 9a decimal ( 10radix) compressing digital 4bytes. The storage of the integer part and the decimal part of each value is determined separately. Each 9digit requires 4bytes remaining digits required 4part of bytes. The following table shows the storage space required for extra numbers.
| Number of remaining digits | Number of bytes required |
|---|---|
| 0 | 0 |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 3 |
| 6 | 3 |
| 7 | 4 |
| 8 | 4 |
Date and time type storage requirements
For TIME, DATETIMEand TIMESTAMPcolumns, tables created before MySQL 5.6.4 and tables created after 5.6.4 require different storage. This is because these types are allowed to have a fractional part in 5.6.4, which requires up 0to 310 bytes.
| type of data | Storage requirements before MySQL 5.6.4 | Storage requirements for MySQL 5.6.4 |
|---|---|---|
| YEAR | 1 byte | 1 byte |
| DATE | 3 bytes | 3 bytes |
| TIME | 3 bytes | 3 bytes + fractional seconds storage |
| DATETIME | 8 bytes | 5 bytes + fractional seconds storage |
| TIMESTAMP | 4 bytes | 4 bytes + fractional seconds storage |
Starting from MySQL 5.6.4, the stored YEARsum DATEremains unchanged. However, the representation of TIME, DATETIMEand TIMESTAMPis different. DATETIMEThe packing efficiency of is higher. For the non-fractional part, it needs 5bytes instead 8of bytes, and all three parts have a fractional part, which needs 0to be from to 3bytes, depending on the precision of the stored fractional seconds value.
| Accurate to fractional seconds | Storage requirements |
|---|---|
| 0 | 0 bytes |
| 1,2 | 1 byte |
| 3,4 | 2 bytes |
| 5,6 | 3 bytes |
For TIME(0)example, TIME(2), , TIME(4)and TIME(6)are used 3, 4, 5and 6bytes. TIMEThe sum TIME(0)is equivalent and requires the same storage space.
String storage requirements
In the following table, the Mdeclared column length is expressed, the non-binary string type is expressed in characters, and the binary string type is expressed in bytes. LRepresents the actual length (in bytes) of a given string value.
| type of data | Storage requirements |
|---|---|
CHAR(M) |
The compact InnoDB row format family optimizes the storage of variable-length character sets. See 15.10 InnoDB row format . Otherwise, M × w bytes, 0 <= M <= 255, where w is the number of bytes required for the maximum length character in the character set. |
BINARY(M) |
M bytes, 0 <= M <= 255 |
VARCHAR(M)，VARBINARY(M) |
L + 1 byte, if the column value needs 0−255 bytes, L + 2 bytes, if the value may need more than 255 bytes |
TINYBLOB，TINYTEXT |
L + 1 byte, where L <2E8 |
BLOB，TEXT |
L + 2 bytes, where L <2E16 |
MEDIUMBLOB，MEDIUMTEXT |
L + 3 bytes, where L <2E24 |
LONGBLOB，LONGTEXT |
L + 4 bytes, where L <2E32 |
ENUM('value1','value2',...) |
1 或 2 字节，取决于枚举值的数量（最大为 65,535 个值） |
SET('value1','value2',...) |
1、2、3、4 或 8 个字节，取决于 set 成员的数量（最大 64 个成员） |
可变长度字符串类型使用长度前缀加数据存储。根据数据类型，长度前缀需要1到4个字节，字符串的字节长度为L。例如，存储一个MEDIUMTEXT值需要L个字节来存储该值，再加上3个字节来存储该值的长度。
要计算用于存储特定CHAR、VARCHAR或TEXT列值的字节数，必须考虑用于该列的字符集以及该值是否包含多字节字符。特别是，在使用utf8 Unicode 字符集时，必须记住并非所有字符使用相同的字节数。utf8mb3和utf8mb4字符集可以分别要求每个字符最多3个字节和4个字节。对于不同类型utf8mb3或utf8mb4字符的存储，请参见 10.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字符每个字符最多需要4个字节，因此可以将使用utf8mb4字符集的VARCHAR列声明为最大16383个字符。参见 8.4.7 对表列数和行大小的限制。
InnoDB将长度大于等于768字节的定长字段编码为可变长字段，可以在页外存储。例如，如果字符集的最大字节长度大于3，例如utf8mb4，CHAR(255)列就可以超过768字节。
NDB存储引擎支持可变宽度列。这意味着NDB Cluster表中的VARCHAR列需要与任何其他存储引擎相同的存储量，只是这些值是4字节对齐的。因此，使用latin1字符集存储在VARCHAR(50)列中的字符串'abcd'需要8个字节（而不是MyISAM表中的相同列值需要5个字节）。
TEXT和BLOB列在NDB中实现不同；TEXT列中的每一行都由两个单独的部分组成。其中一个具有固定大小（256字节），实际上存储在原始表中。另一个由超过256字节的数据组成，这些数据存储在一个隐藏的表中。第二个表中的行总是2000字节长。这意味着如果size <= 256（其中size表示行的大小），则文本列的大小为256；否则为256 + size + (2000 × (size−256)% 2000)。
ENUM对象的大小由不同枚举值的数量决定。一个字节用于最多255个可能值的枚举。两个字节用于256到65,535个可能值之间的枚举。参见 11.3.5 ENUM 类型。
SET对象的大小由不同SET成员的数量决定。如果设置的大小为N，则对象占用(N+7)/8个字节，四舍五入到1、2、3、4或8个字节。一个集合最多可以有64个成员。参见 11.3.6 SET 类型。
空间类型存储要求
MySQL 使用4个字节存储几何值，以指示 SRID，后面是值的 WKB 表示。LENGTH()函数的作用是以字节为单位返回存储值所需的空间。
关于 WKB 和空间值的内部存储格式的描述，请参见 11.4.3 支持的空间数据格式。
JSON 类型存储要求
一般来说，JSON列的存储需求与LONGBLOB或LONGTEXT列的存储需求大致相同；也就是说，JSON文档所消耗的空间与存储在这些类型之一的列中的文档字符串表示所消耗的空间大致相同。但是，存储在JSON文档中的单个值的二进制编码（包括查找所需的元数据和字典）会带来额外的开销。例如，存储在JSON文档中的字符串需要4到10个字节的额外存储，这取决于字符串的长度和存储它的对象或数组的大小。
另外，MySQL 对JSON列中存储的任何JSON文档的大小施加了限制，不能超过max_allowed_packet的值。