The storage requirements for data vary, according to the storage engine being used for the table in question. Different storage engines use different methods for recording the raw data and different data types. In addition, some engines may compress the information in a given row, either on a column or entire row basis, making calculation of the storage requirements for a given table or column structure.
However, all storage engines must communicate and exchange information on a given row within a table using the same structure, and this information is consistent, irrespective of the storage engine used to write the information to disk.
This sections includes some guideliness and information for the storage requirements for each data type supported by MySQL, including details for the internal format and the sizes used by storage engines that used a fixed size representation for different types. Information is listed by category or storage engine.
The maximum size of a row in a MyISAM table is
65,535 bytes. This figure excludes
BLOB or
TEXT columns, which contribute only
9 to 12 bytes toward this size.
The internal representation of a table also has a maximum row size
of 65,535 bytes, even if the storage engine is capable of
supporting larger rows. For BLOB
and TEXT data, the information is
stored internally in a different area of memory than the row
buffer. 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. See
Chapter 13, Storage Engines, for more information.
For tables using the NDBCLUSTER
storage engine, there is the factor of 4-byte
alignment to be taken into account when calculating
storage requirements. This means that all
NDB data storage is done in
multiples of 4 bytes. Thus, a column value that would take 15
bytes in a table using a storage engine other than
NDB requires 16 bytes in an
NDB table. This requirement applies
in addition to any other considerations that are discussed in
this section. For example, in
NDBCLUSTER tables, the
TINYINT,
SMALLINT,
MEDIUMINT, and
INTEGER
(INT) column types each require 4
bytes storage per record due to the alignment factor.
An exception to this rule is the
BIT type, which is
not 4-byte aligned. In MySQL Cluster
tables, a BIT(
column takes M)M bits of storage space.
However, if a table definition contains 1 or more
BIT columns (up to 32
BIT columns), then
NDBCLUSTER reserves 4 bytes (32
bits) per row for these. If a table definition contains more
than 32 BIT columns (up to 64
such columns), then NDBCLUSTER
reserves 8 bytes (that is, 64 bits) per row.
In addition, while a NULL itself does not
require any storage space,
NDBCLUSTER reserves 4 bytes per row
if the table definition contains any columns defined as
NULL, up to 32 NULL
columns. (If a MySQL Cluster table is defined with more than 32
NULL columns up to 64 NULL
columns, then 8 bytes per row is reserved.)
When calculating storage requirements for MySQL Cluster tables,
you must also remember that every table using the
NDBCLUSTER storage engine requires a
primary key; if no primary key is defined by the user, then a
“hidden” primary key will be created by
NDB. This hidden primary key consumes
31-35 bytes per table record.
You may find the ndb_size.pl utility to be
useful for estimating NDB storage
requirements. This Perl script connects to a current MySQL
(non-Cluster) database and creates a report on how much space that
database would require if it used the
NDBCLUSTER storage engine. See
ndb_size.pl, for more
information.
Storage Requirements for Numeric Types
| Data Type | Storage Required |
|---|---|
TINYINT | 1 byte |
SMALLINT | 2 bytes |
MEDIUMINT | 3 bytes |
INT,
INTEGER | 4 bytes |
BIGINT | 8 bytes |
FLOAT( | 4 bytes if 0 <= p <= 24, 8 bytes if 25
<= p <= 53 |
FLOAT | 4 bytes |
DOUBLE [PRECISION],
REAL | 8 bytes |
DECIMAL(,
NUMERIC( | Varies; see following discussion |
BIT( | approximately (M+7)/8 bytes |
Values for DECIMAL (and
NUMERIC) columns are represented
using a binary format that packs nine decimal (base 10) digits
into four bytes. 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.
| Leftover Digits | Number of Bytes |
|---|---|
| 0 | 0 |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 3 |
| 6 | 3 |
| 7 | 4 |
| 8 | 4 |
Storage Requirements for Date and Time Types
The storage requirements shown in the table arise from the way that MySQL represents temporal values:
DATE: A three-byte integer packed asDD+MM×32 +YYYY×16×32TIME: A three-byte integer packed asDD×24×3600 +HH×3600 +MM×60 +SSDATETIME: Eight bytes:A four-byte integer packed as
YYYY×10000 +MM×100 +DDA four-byte integer packed as
HH×10000 +MM×100 +SS
TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00'UTC)YEAR: A one-byte integer
Storage Requirements for String Types
In the following table, M represents
the declared column length in characters for nonbinary string
types and bytes for binary string types.
L represents the actual length in bytes
of a given string value.
| Data Type | Storage Required |
|---|---|
CHAR( | M × w bytes,
0 <= 255, where w is
the number of bytes required for the maximum-length
character in the character set |
BINARY( | M bytes, 0 <=
255 |
VARCHAR(,
VARBINARY( | L + 1 bytes if column values require 0
– 255 bytes, L + 2 bytes
if values may require more than 255 bytes |
TINYBLOB,
TINYTEXT | L + 1 bytes, where
L <
28 |
BLOB, TEXT | L + 2 bytes, where
L <
216 |
MEDIUMBLOB,
MEDIUMTEXT | L + 3 bytes, where
L <
224 |
LONGBLOB,
LONGTEXT | L + 4 bytes, where
L <
232 |
ENUM(' | 1 or 2 bytes, depending on the number of enumeration values (65,535 values maximum) |
SET(' | 1, 2, 3, 4, or 8 bytes, depending on the number of set members (64 members maximum) |
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
L (the byte length of the string). For
example, storage for a MEDIUMTEXT
value requires L bytes to store the
value plus three bytes to store the length of the value.
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 multi-byte characters. In particular, when
using the utf8 (or utf8mb4)
Unicode character set, you must keep in mind that not all
characters use the same number of bytes and can require up to
three (four) bytes per character. For a breakdown of the storage
used for different categories of utf8 or
utf8mb4 characters, see
Section 9.1.10, “Unicode Support”.
VARCHAR,
VARBINARY, and the
BLOB and
TEXT types are variable-length
types. 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 multi-byte characters
For example, a VARCHAR(255) column can hold a
string with a maximum length of 255 characters. 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. For the string 'abcd',
L is 4 and the storage requirement is
five bytes. If the same column is instead declared to use the
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).
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. For a VARCHAR column
that stores multi-byte characters, the effective maximum number
of characters is less. For example,
utf8 characters can require up to three bytes
per character, so a VARCHAR
column that uses the utf8 character set can
be declared to be a maximum of 21,844 characters.
The size of an ENUM object is
determined by the number of different enumeration values. One byte
is used for enumerations with up to 255 possible values. Two bytes
are used for enumerations having between 256 and 65,535 possible
values. See Section 10.4.4, “The ENUM Type”.
The size of a SET object is
determined by the number of different set members. If the set size
is N, the object occupies
( bytes,
rounded up to 1, 2, 3, 4, or 8 bytes. A
N+7)/8SET can have a maximum of 64
members. See Section 10.4.5, “The SET Type”.