InnoDB's index achieved

InnoDB two categories index

• Clustered index (clustered index)

• General index (secondary index)

Leaf node stores rows InnoDB clustered index, therefore, must be InnoDB, and only one clustered index

(1) If the table is defined PK, PK is the clustered index;

(2) If the table is not defined PK, then the first column is not NULL unique clustered index;

(3) Otherwise, InnoDB will create a hidden row-id as a clustered index;

Voiceover: So PK queries very fast, positioned directly rows.

InnoDB general index leaf node stores the primary key value.

VO: Note that, instead of the recording head pointer memory row, the record pointer index leaf node stores the MyISAM.

If the following table:

user(id PK, name Key ,sex)

Wherein the table has four data:

1, zhangsan, 19

3, lysis, 22

5, wanger  29

9, mazhi 10

 

 

B + tree index two are shown above:

(1) id as PK, clustered index, the leaf node stores rows;

(2) name as the KEY, the general index, the leaf node stores PK values, i.e., ID;

Since the general index can not be positioned directly rows, and that the general index of the query process is kind of how it?

Typically, the code needs to be scanned twice index tree.

 

 This is called back to the table query, first locate the primary key value, and then locate the line record, its performance is lower than the sweep over the index tree.

Actual quote:

 

 

 FIG combination index structure:

create table t1 (a int primary key, b int, c int, d int, e varchar(20));

create index idx_t1_bcd on t1(b, c, d);

 insert into t1 values (4,3,1,1,’d’);

insert into t1 values (1,1,1,1,’a’);

insert into t1 values (8,8,8,8,’h’):

insert into t1 values (2,2,2,2,’b’);

insert into t1 values (5,2,3,5,’e’);

insert into t1 values (3,3,2,2,’c’);

insert into t1 values (7,4,5,5,’g’);

insert into t1 values (6,6,4,4,’f’);