The storage requirements for table data on disk depend on several factors. 表数据在磁盘上的存储要求取决于几个因素。Different storage engines represent data types and store raw data differently. 不同的存储引擎表示不同的数据类型，并以不同的方式存储原始数据。Table data might be compressed, either for a column or an entire row, complicating the calculation of storage requirements for a table or column.表数据可能会被压缩，无论是针对一列还是整行，这会使表或列的存储需求计算变得复杂。
Despite differences in storage layout on disk, the internal MySQL APIs that communicate and exchange information about table rows use a consistent data structure that applies across all storage engines.尽管磁盘上的存储布局有所不同，但用于通信和交换表行信息的内部MySQL api使用了一种适用于所有存储引擎的一致数据结构。
This section includes guidelines and information for the storage requirements for each data type supported by MySQL, including the internal format and size for storage engines that use a fixed-size representation for data types. 本节包括MySQL支持的每种数据类型的存储要求的指导原则和信息，包括使用固定大小表示的数据类型的存储引擎的内部格式和大小。Information is listed by category or storage engine.信息按类别或存储引擎列出。
The internal representation of a table has a maximum row size of 65,535 bytes, even if the storage engine is capable of supporting larger rows. 表的内部表示具有65535字节的最大行大小，即使存储引擎能够支持较大的行。This figure excludes 这个数字不包括BLOB or TEXT columns, which contribute only 9 to 12 bytes toward this size. BLOB或TEXT列，它们只贡献了9到12个字节。For 对于BLOB and TEXT data, the information is stored internally in a different area of memory than the row buffer. BLOB和TEXT数据，信息存储在与行缓冲区不同的内存区域中。Different storage engines handle the allocation and storage of this data in different ways, according to the method they use for handling the corresponding types. 不同的存储引擎根据用于处理相应类型的方法，以不同的方式处理这些数据的分配和存储。For more information, see Chapter 16, Alternative Storage Engines, and Section 8.4.7, “Limits on Table Column Count and Row Size”.有关更多信息，请参阅第16章，“替代存储引擎”和第8.4.7节，“表列计数和行大小限制”。
See Section 15.10, “InnoDB Row Formats” for information about storage requirements for 有关InnoDB tables.InnoDB表存储要求的信息，请参阅第15.10节，“InnoDB行格式”。
NDB tables use 4-byte alignment; all NDB data storage is done in multiples of 4 bytes. NDB表使用4字节对齐方式；所有NDB数据存储都是4字节的倍数。Thus, a column value that would typically take 15 bytes requires 16 bytes in an 因此，通常需要15字节的列值需要NDB table. NDB表中的16字节。For example, in 例如，在NDB表中，NDB tables, the TINYINT, SMALLINT, MEDIUMINT, and INTEGER (INT) column types each require 4 bytes storage per record due to the alignment factor.TINYINT、SMALLINT、MEDIUMINT和INTEGER(INT)列类型由于对齐因子，每个记录都需要4字节的存储空间。
Each 每一BIT( column takes M)M bits of storage space. BIT(列占用M位的存储空间。M)Although an individual 尽管单个BIT column is not 4-byte aligned, NDB reserves 4 bytes (32 bits) per row for the first 1-32 bits needed for BIT columns, then another 4 bytes for bits 33-64, and so on.BIT列不是4字节对齐的，但NDB为每行保留4字节（32位），用于BIT列所需的第一个1-32位，然后为33-64位保留另一个4字节，依此类推。
While a 虽然NULL itself does not require any storage space, NDB reserves 4 bytes per row if the table definition contains any columns allowing NULL, up to 32 NULL columns. NULL本身不需要任何存储空间，但如果表定义包含允许NULL的任何列（最多32个NULL列），NDB将为每行保留4个字节。(If an NDB Cluster table is defined with more than 32 （如果NDB群集表定义有32个以上的NULL columns up to 64 NULL columns, then 8 bytes per row are reserved.)NULL列（最多64个NULL列），则每行保留8个字节。）
Every table using the 使用NDB storage engine requires a primary key; if you do not define a primary key, a “hidden” primary key is created by NDB. NDB存储引擎的每个表都需要一个主键；如果未定义主键，NDB将创建一个“隐藏”主键。This hidden primary key consumes 31-35 bytes per table record.这个隐藏的主键每个表记录消耗31-35字节。
You can use the ndb_size.pl Perl script to estimate 您可以使用ndb_size.pl Perl脚本来估计ndb存储需求。NDB storage requirements. It connects to a current MySQL (not NDB Cluster) database and creates a report on how much space that database would require if it used the 它连接到当前的MySQL(不是NDB storage engine. NDB集群）数据库，并创建一个报告，说明如果使用NDB存储引擎，该数据库将需要多少空间。See Section 23.4.28, “ndb_size.pl — NDB CLUSTER Size Requirement Estimator” for more information.有关更多信息，请参阅第23.4.28节“ndb_size.pl——NDB群集大小需求估算”。
TINYINT | |
SMALLINT | |
MEDIUMINT | |
INT, INTEGER | |
BIGINT | |
FLOAT( | p <= 24, 8 bytes if 25 <= p <= 53p <= 24则为4字节，如果25 <= p <= 53则为8字节。 |
FLOAT | |
DOUBLE [PRECISION],
REAL | |
DECIMAL(,
NUMERIC( | |
BIT( | M+7)/8 bytesM+7)/8字节 |
Values for DECIMAL (and NUMERIC) columns are represented using a binary format that packs nine decimal (base 10) digits into four bytes. DECIMAL（和NUMERIC）列的值使用二进制格式表示，该格式将九个十进制（以10为基数）数字压缩为四个字节。Storage for the integer and fractional parts of each value are determined separately. 每个值的整数部分和小数部分的存储分别确定。Each multiple of nine digits requires four bytes, and the “leftover” digits require some fraction of four bytes. 九位数的每一个倍数需要四个字节，“剩余”位数需要四个字节的一小部分。The storage required for excess digits is given by the following table.下表给出了多余数字所需的存储空间。
| 0 | 0 |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 3 |
| 6 | 3 |
| 7 | 4 |
| 8 | 4 |
For 对于TIME, DATETIME, and TIMESTAMP columns, the storage required for tables created before MySQL 5.6.4 differs from tables created from 5.6.4 on. TIME、DATETIME和TIMESTAMP列，MySQL5.6.4之前创建的表所需的存储空间与5.6.4之后创建的表不同。This is due to a change in 5.6.4 that permits these types to have a fractional part, which requires from 0 to 3 bytes.这是由于5.6.4中的一个更改，允许这些类型有一个小数部分，需要0到3个字节。
YEAR | ||
|---|---|---|
DATE | ||
TIME | ||
DATETIME | ||
TIMESTAMP |
As of MySQL 5.6.4, storage for 从MySQL5.6.4开始，YEAR and DATE remains unchanged. YEAR和DATE的存储保持不变。However, 但是，TIME, DATETIME, and TIMESTAMP are represented differently. TIME、DATETIME和TIMESTAMP的表示方式不同。DATETIME is packed more efficiently, requiring 5 rather than 8 bytes for the nonfractional part, and all three parts have a fractional part that requires from 0 to 3 bytes, depending on the fractional seconds precision of stored values.DATETIME的打包效率更高，非分式部分需要5字节而不是8字节，而且所有三个部分都有一个分式部分，需要0到3字节，这取决于存储值的分式秒精度。
| 0 | |
| 1, 2 | |
| 3, 4 | |
| 5, 6 |
For example, 例如，TIME(0), TIME(2), TIME(4), and TIME(6) use 3, 4, 5, and 6 bytes, respectively. TIME(0)、TIME(2)、TIME(4)和TIME(6)分别使用3、4、5和6字节。TIME and TIME(0) are equivalent and require the same storage.
For details about internal representation of temporal values, see MySQL Internals: Important Algorithms and Structures.有关时态值的内部表示的详细信息，请参阅MySQL内部：重要的算法和结构。
In the following table, 在下表中，M represents the declared column length in characters for nonbinary string types and bytes for binary string types. M表示以字符表示的非二进制字符串类型的声明列长度，以字节表示的二进制字符串类型的声明列长度。L represents the actual length in bytes of a given string value.L表示给定字符串值的实际长度（以字节为单位）。
CHAR( | M × w bytes, <= 255, where w is the number of bytes required for the maximum-length character in the character set.M × w字节，<= 255，其中w是字符集中最大长度字符所需的字节数。 |
BINARY( | M bytes, 0 <= 255M字节，0 <= M <= 255 |
VARCHAR(, VARBINARY( | L + 1 bytes if column values require 0 − 255 bytes, L + 2 bytes if values may require more than 255 bytesL+1字节；如果值可能需要超过255字节，则为L+2字节 |
TINYBLOB, TINYTEXT | L + 1 bytes, where L < 28L+1字节，其中L < 28 |
BLOB, TEXT | L + 2 bytes, where L < 216L+2字节，其中L < 216 |
MEDIUMBLOB, MEDIUMTEXT | L + 3 bytes, where L < 224L+3字节，其中L |
LONGBLOB, LONGTEXT | L + 4 bytes, where L < 232L+4字节，其中L < 232 |
ENUM(' | |
SET(' |
Variable-length string types are stored using a length prefix plus data. 可变长度字符串类型使用长度前缀和数据存储。The length prefix requires from one to four bytes depending on the data type, and the value of the prefix is 长度前缀需要1到4个字节，具体取决于数据类型，前缀的值是L (the byte length of the string). L(字符串的字节长度）。For example, storage for a 例如，存储MEDIUMTEXT value requires L bytes to store the value plus three bytes to store the length of the value.MEDIUMTEXT值需要L个字节来存储该值，再加上3个字节来存储该值的长度。
To calculate the number of bytes used to store a particular 要计算用于存储特定CHAR, VARCHAR, or TEXT column value, you must take into account the character set used for that column and whether the value contains multibyte characters. CHAR、VARCHAR或TEXT列值的字节数，必须考虑用于该列的字符集以及该值是否包含多字节字符。In particular, when using a 特别是，在使用utf8 Unicode character set, you must keep in mind that not all characters use the same number of bytes. utf8unicode字符集时，必须记住并非所有字符都使用相同的字节数。utf8mb3 and utf8mb4 character sets can require up to three and four bytes per character, respectively. utf8mb3和utf8mb4字符集每个字符最多分别需要3个和4个字节。For a breakdown of the storage used for different categories of 有关用于不同类别utf8mb3 or utf8mb4 characters, see Section 10.9, “Unicode Support”.utf8mb3或utf8mb4字符的存储的详细信息，请参阅第10.9节，“Unicode支持”。
VARCHAR, VARBINARY, and the BLOB and TEXT types are variable-length types. VARCHAR、VARBINARY以及BLOB和TEXT类型都是可变长度类型。For each, the storage requirements depend on these factors:对于每种类型，储存要求取决于以下因素：
The actual length of the column value列值的实际长度
The column's maximum possible length列的最大可能长度
The character set used for the column, because some character sets contain multibyte characters用于列的字符集，因为某些字符集包含多字节字符
For example, a 例如，VARCHAR(255) column can hold a string with a maximum length of 255 characters. VARCHAR(255)列可以容纳最大长度为255个字符的字符串。Assuming that the column uses the 假设列使用latin1 character set (one byte per character), the actual storage required is the length of the string (L), plus one byte to record the length of the string. latin1字符集（每个字符一个字节），实际需要的存储是字符串的长度（L）加上一个字节来记录字符串的长度。For the string 对于字符串'abcd', L is 4 and the storage requirement is five bytes. 'abcd'，L是4，存储要求是5个字节。If the same column is instead declared to use the 如果将同一列声明为使用ucs2双字节字符集，则存储要求为10字节：ucs2 double-byte character set, the storage requirement is 10 bytes: The length of 'abcd' is eight bytes and the column requires two bytes to store lengths because the maximum length is greater than 255 (up to 510 bytes).'abcd'的长度为8字节，而该列需要两个字节来存储长度，因为最大长度大于255(最多510字节）。
The effective maximum number of bytes that can be stored in a VARCHAR or VARBINARY column is subject to the maximum row size of 65,535 bytes, which is shared among all columns. VARCHAR或VARBINARY列中可存储的有效最大字节数受所有列共享的最大行大小65535字节的限制。For a 对于存储多字节字符的VARCHAR column that stores multibyte characters, the effective maximum number of characters is less. VARCHAR列，有效的最大字符数较少。For example, 例如，utf8mb4 characters can require up to four bytes per character, so a VARCHAR column that uses the utf8mb4 character set can be declared to be a maximum of 16,383 characters. utf8mb4字符每个字符最多需要4个字节，因此使用utf8mb4字符集的VARCHAR列可以声明为最多16383个字符。See Section 8.4.7, “Limits on Table Column Count and Row Size”.请参阅第8.4.7节，“表列计数和行大小限制”。
InnoDB encodes fixed-length fields greater than or equal to 768 bytes in length as variable-length fields, which can be stored off-page. InnoDB将长度大于或等于768字节的固定长度字段编码为可变长度字段，可以在页外存储。For example, a 例如，如果字符集的最大字节长度大于3，则CHAR(255) column can exceed 768 bytes if the maximum byte length of the character set is greater than 3, as it is with utf8mb4.CHAR(255)列可以超过768字节，就像utf8mb4一样。
The NDB storage engine supports variable-width columns. NDB存储引擎支持可变宽度列。This means that a 这意味着NDB集群表中的VARCHAR column in an NDB Cluster table requires the same amount of storage as would any other storage engine, with the exception that such values are 4-byte aligned. VARCHAR列需要与任何其他存储引擎相同的存储量，只是这些值是4字节对齐的。Thus, the string 因此，使用拉丁字符集存储在'abcd' stored in a VARCHAR(50) column using the latin1 character set requires 8 bytes (rather than 5 bytes for the same column value in a MyISAM table).VARCHAR(50)列中的字符串'abcd'需要8个字节（而不是MyISAM表中相同列值的5个字节）。
TEXT and BLOB columns are implemented differently in NDB; each row in a TEXT column is made up of two separate parts. TEXT和BLOB列在NDB中的实现方式不同；文本列中的每一行都由两个独立的部分组成。One of these is of fixed size (256 bytes), and is actually stored in the original table. 其中一个是固定大小（256字节），实际上存储在原始表中。The other consists of any data in excess of 256 bytes, which is stored in a hidden table. 另一个由任何超过256字节的数据组成，这些数据存储在一个隐藏表中。The rows in this second table are always 2000 bytes long. 第二个表中的行总是2000字节长。This means that the size of a 这意味着如果TEXT column is 256 if size <= 256 (where size represents the size of the row); otherwise, the size is 256 + size + (2000 × (size − 256) % 2000).size <= 256，则TEXT列的大小是256（其中size代表行的大小）；否则，TEXT列的大小是256 + size + (2000 × (size − 256) % 2000)。
The size of an ENUM object is determined by the number of different enumeration values. ENUM对象的大小由不同枚举值的数目决定。One byte is used for enumerations with up to 255 possible values. 一个字节用于最多255个可能值的枚举。Two bytes are used for enumerations having between 256 and 65,535 possible values. 两个字节用于具有256到65535个可能值的枚举。See Section 11.3.5, “The ENUM Type”.参见第11.3.5节，“枚举类型”。
The size of a SET object is determined by the number of different set members. SET对象的大小由不同集合成员的数量决定。If the set size is 如果设置的大小为N, the object occupies ( bytes, rounded up to 1, 2, 3, 4, or 8 bytes. N+7)/8N，则对象占用(字节，四舍五入为1、2、3、4或8字节。N+7)/8A 一个SET can have a maximum of 64 members. SET最多可以有64个成员。See Section 11.3.6, “The SET Type”.见第11.3.6节，“集合类型”。
MySQL stores geometry values using 4 bytes to indicate the SRID followed by the WKB representation of the value. MySQL使用4个字节存储几何值，以指示SRID，后跟值的WKB表示。The LENGTH() function returns the space in bytes required for value storage.LEHGTH函数的作用是：返回值存储所需的字节空间。
For descriptions of WKB and internal storage formats for spatial values, see Section 11.4.3, “Supported Spatial Data Formats”.有关空间值的WKB和内部存储格式的说明，请参阅第11.4.3节，“支持的空间数据格式”。
In general, the storage requirement for a 一般来说，JSON column is approximately the same as for a LONGBLOB or LONGTEXT column; that is, the space consumed by a JSON document is roughly the same as it would be for the document's string representation stored in a column of one of these types. JSON列的存储需求与LONGBLOB或LONGTEXT列大致相同；也就是说，JSON文档所占用的空间与存储在这些类型之一的列中的文档字符串表示的空间大致相同。However, there is an overhead imposed by the binary encoding, including metadata and dictionaries needed for lookup, of the individual values stored in the JSON document. 但是，二进制编码（包括查找JSON文档中存储的单个值所需的元数据和字典）会带来一定的开销。For example, a string stored in a JSON document requires 4 to 10 bytes additional storage, depending on the length of the string and the size of the object or array in which it is stored.例如，存储在JSON文档中的字符串需要4到10字节的额外存储空间，这取决于字符串的长度以及存储该字符串的对象或数组的大小。
In addition, MySQL imposes a limit on the size of any JSON document stored in a 此外，MySQL对存储在JSON column such that it cannot be any larger than the value of max_allowed_packet.JSON列中的任何JSON文档的大小都施加了限制，使得它不能大于max_allowed_packet的值。