Index (Index) to help MySQL efficiently get the data structure of the data.
MyISAM index achieved
MyISAM engine used as a B + Tree index structure, leaf node is stored in the address data field of the data record. The figure is a schematic diagram of MyISAM index:
here provided a total of three tables, we assume Col1 primary key, the primary index is a 8 MyISAM tables (Primary key) schematically. It can be seen MyISAM index file only save the address data records. In MyISAM, the main index and a secondary index (Secondary key) without any difference in structure, but the main index key requirement is unique, and the auxiliary key index may be repeated. If we build a secondary index on Col2, the index of this structure is shown below:
is also a B + Tree, the address data stored in the data field is recorded. Thus, MyISAM index search algorithm first search algorithm in accordance with the B + Tree search index, if the specified Key is present, the value of its data field taken out, then the value of the address data field, reads the corresponding data record.
MyISAM indexes mode is also called "non-clustered", the reason so called to distinguish the InnoDB clustered index.
InnoDB index achieved
InnoDB的数据文件本身就是索引文件。
MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。
上图是InnoDB主索引（同时也是数据文件）的示意图，可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。
第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。例如，图11为定义在Col3上的一个辅助索引：
聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。再例如，用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。
覆盖索引
No matter in any way look-up table, will eventually be using the main keys to navigate to the data by the clustered index, clustered index (primary key) is the only path to real data resides.
However, one exception may not be able to query the index using the aggregate data required, this non-mainstream method is called a covering index the query, which is usually a composite of said multi-field index or index query. When indexed field, the contents of the field will be synchronized to the index in, if you specify two fields into one index, then the two fields will be synchronized to the content being indexed.
Look at the following SQL statement:
//建立索引
create index index_birthday on user_info(birthday);
//查询生日在1991年11月1日出生用户的用户名
select user_name from user_info where birthday = '1991-11-1';
Execution of sentence SQL statement is as follows:
1, first, index_birthday birthday equal to find all records 1991-11-1 the primary key ID value with the non-clustered index;
2, then, the primary key ID value obtained clustered index lookup, to find the position of the master key ID value of real data (line data) to the storage;
3, finally, achieved the user_name field of the data obtained from the real value is returned, which is to win the final result.
We put the index on the birthday field into double coverage index fields:
create index birthday_and_user_name on user_info(birthday,user_name);
Execution of sentence SQL statement will become:
By non-clustered index lookup birthday_and_user_name birthday 1991-11-1 equal to the content of the leaf node, however, in addition to the leaf nodes user_name primary key ID value other than the value of the field user_name also inside, so no primary key ID value Find where real data lines, direct access to the value of the leaf node user_name returns can be. In this way the cover index direct lookup can be omitted without using a two step back cover index lookups, greatly improve the query performance.
