Every InnoDB
table has a special index called
the clustered index where the data for
the rows is stored:
If you define a PRIMARY KEY
on your
table, InnoDB
uses it as the clustered
index.
If you do not define a PRIMARY KEY
for
your table, MySQL picks the first UNIQUE
index that has only NOT NULL
columns as
the primary key and InnoDB
uses it as the
clustered index.
If the table has no PRIMARY KEY
or
suitable UNIQUE
index,
InnoDB
internally generates a hidden
clustered index on a synthetic column containing row ID
values. The rows are ordered by the ID that
InnoDB
assigns to the rows in such a
table. The row ID is a 6-byte field that increases
monotonically as new rows are inserted. Thus, the rows
ordered by the row ID are physically in insertion order.
Accessing a row through the clustered index is fast because the
row data is on the same page where the index search leads. If a
table is large, the clustered index architecture often saves a
disk I/O operation when compared to storage organizations that
store row data using a different page from the index record.
(For example, MyISAM
uses one file for data
rows and another for index records.)
In InnoDB
, the records in nonclustered
indexes (also called secondary indexes) contain the primary key
columns for the row that are not in the secondary index.
InnoDB
uses this primary key value to search
for the row in the clustered index. If the primary key is long,
the secondary indexes use more space, so it is advantageous to
have a short primary key.
User Comments
Add your own comment.