This article from the micro-channel public number
Friends of the water planet continue to answer questions:
Shen teacher, I listen to the Internet, said, MySQL data tables, in the case of large amount of data, primary keys should not be too long, is not it so? This is why?
Well the problem can not be generalized:
(1) If InnoDB storage engine, the primary key should not be too long ;
(2) if it is MyISAM storage engine, has little effect ;
to give a simple chestnut explain the preamble knowledge.
Suppose there are data tables:
T (the PK ID, name KEY, Sex, In Flag);
Wherein:
(. 1) is the primary key ID;
(2) Common name index built;
assuming there are four records in the table:
. 1, shenjian, m, A
3, zhangsan, m, A
5, lisi, I, A
9, wangwu, f, B
If the storage engine is MyISAM, and the structure of its index record is this:
(1) has a separate area for storing records (Record);
the same (2) primary key index and the ordinary index structure are stored pointer to a record (for the time being understood as a pointer);
VO:
(1) primary key index of the recording is not stored together, Thus it is a non-clustered index (index unclustered);
(2) may not have the PK MyISAM;
when used MyISAM index search will start index tree to locate the record pointer, and then target specific recording by the recording pointer.
Narrator: Whether the primary key index, but also the general index, the same process.
InnoDB is different, which is the index of the recording structure is such that:
(1) primary key index with records stored together;
(2) general index storing the primary key (which is lower than a pointer of);
VO:
(1) primary key index with records stored together, so called aggregation index ( 'Clustered Index);
( 2) InnoDB there will be aggregation index;
the InnoDB by query primary key index , it is possible directly positioned to the rows.
But if by query ordinary index , the query will be first out of the main key, and then from the primary key index of the secondary traversing the index tree .
Now the question, Why InnoDB primary key should not be too long then ?
Suppose you have a user-centered scenarios including ID number, ID MD5, name, date of birth and other business properties, these properties have a query on demand.
The easiest way is to think of design:
ID as the primary key
Other property index
user(id_code PK,
id_md5(index),
name(index),
birthday(index));
At this time, the row index tree record structure described above:
- id_code clustered index, rows association
- Other indexing, storage id_code property values
ID number id_code is a long string, each index to store the value in the case of large volume of data, a precious memory, MySQL limited buffer storage of index and data will reduce the probability of disk IO will increase .
Narrator: At the same time, the index will increase the amount of disk space.
At this point, it should be no business meaning of a new id auto-increment :
- With an auto-increment id for the clustered index, rows association
- Other indexes, stored value id
user(id PK auto inc,
id_code(index),
id_md5(index),
name(index),
birthday(index));
In this way, the limited buffer, the buffer can be more indexes and rows of data, disk IO will reduce the frequency, the overall performance will increase.
Summary
(1) MyISAM index and data separately, index leaf store pointers, the primary key index and the ordinary index no big difference;
(2) the InnoDB clustered index and data lines unified storage, clustered index store data row itself, ordinary index storage primary key;
(. 3) the InnoDB is not recommended as a long field PK (this case may be added by a self key PK), MyISAM it does not matter;
I want to answer the questions of the Friends of the water.