The physical record structure for InnoDB tables is dependent on
the MySQL version and the optional ROW_FORMAT
option used when the table was created. For InnoDB tables in
MySQL earlier than 5.0.3, only the REDUNDANT
row format was available. For MySQL 5.0.3 and later, the default
is to use the COMPACT row format, but you can
use the REDUNDANT format to retain
compatibility with older versions of InnoDB tables.
Records in InnoDB ROW_FORMAT=REDUNDANT tables
have the following characteristics:
Each index record contains a six-byte header. The header is used to link together consecutive records, and also in row-level locking.
Records in the clustered index contain fields for all user-defined columns. In addition, there is a six-byte field for the transaction ID and a seven-byte field for the roll pointer.
If no primary key was defined for a table, each clustered index record also contains a six-byte row ID field.
Each secondary index record contains also all the fields defined for the clustered index key.
A record contains also a pointer to each field of the record. If the total length of the fields in a record is less than 128 bytes, the pointer is one byte; otherwise, two bytes. The array of these pointers is called the record directory. The area where these pointers point is called the data part of the record.
Internally, InnoDB stores fixed-length character columns
such as CHAR(10) in a fixed-length
format. InnoDB truncates trailing spaces from
VARCHAR columns.
An SQL NULL value reserves 1 or 2 bytes
in the record directory. Besides that, an SQL
NULL value reserves zero bytes in the
data part of the record if stored in a variable length
column. In a fixed-length column, it reserves the fixed
length of the column in the data part of the record. The
motivation behind reserving the fixed space for
NULL values is that it enables an update
of the column from NULL to a
non-NULL value to be done in place
without causing fragmentation of the index page.
Records in InnoDB ROW_FORMAT=COMPACT tables
have the following characteristics:
Each index record contains a five-byte header that may be preceded by a variable-length header. The header is used to link together consecutive records, and also in row-level locking.
The record header contains a bit vector for indicating
NULL columns. The bit vector occupies
(n_nullable+7)/8 bytes. Columns that are
NULL will not occupy other space than the
bit in this vector.
For each non-NULL variable-length field,
the record header contains the length of the column in one
or two bytes. Two bytes will only be needed if part of the
column is stored externally or the maximum length exceeds
255 bytes and the actual length exceeds 127 bytes.
The record header is followed by the data contents of the
columns. Columns that are NULL are
omitted.
Records in the clustered index contain fields for all user-defined columns. In addition, there is a six-byte field for the transaction ID and a seven-byte field for the roll pointer.
If no primary key was defined for a table, each clustered index record also contains a six-byte row ID field.
Each secondary index record contains also all the fields defined for the clustered index key.
Internally, InnoDB stores fixed-length, fixed-width
character columns such as CHAR(10) in a
fixed-length format. InnoDB truncates trailing spaces from
VARCHAR columns.
Internally, InnoDB attempts to store UTF-8
CHAR( columns in
n)n bytes by trimming trailing spaces. In
ROW_FORMAT=REDUNDANT, such columns occupy
3*n bytes. The motivation behind
reserving the minimum space n is that it
in many cases enables an update of the column to be done in
place without causing fragmentation of the index page.
The presence of the compact row format decreases row storage space by about 20% at the cost of increasing CPU use for some operations. If your workload is a typical one that is limited by cache hit rates and disk speed it is likely to be faster. If it is a rare case that is limited by CPU speed, it might be slower.


User Comments
Add your own comment.