关于mysql的聚集索引

翻译：

 

InnoDB表会包含一个聚集索引（数据表的物理存储顺序和表的逻辑存储顺序一致）

一般是按照下面的规则来设定聚集索引的：

1，假如表包含PRIMARY KEY，InnoDB使用它作为聚集索引

2，假如表没有定义PRIMARY KEY，InnoDB将第一个只包含NOT NULL属性列的UNIQUE index作为主键并且将它设置为聚集索引

3，前两者都不满足的时候，mysql就增加一个隐藏的autocreament

 

 

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.

 

原文地址：http://dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html