MySQL: Pourquoi ma longueur d'index est-elle de 0.0 octets?

Question

J'ai une table simple contenant 4 colonnes.

colonne A (int), la colonne B (int), la colonne C (int), la colonne D (int)

j'ai construit un index sur (colonne B, colonne A, colonne C), qui travaille bien la performance sage. Ma table contient 5 millions de lignes, et l'utilisation de l'index pour sélectionner les lignes désirées fonctionne instantanément (< 0,00 s). Pendant l'inspection de la table, cependant, je vois que ma longueur de l'index est de 0.0 octets. Pourquoi? Comment mon index ne peut-il prendre aucun souvenir?

Info:

SHOW CREATE TABLE kpi_store_hour

CREATE TABLE kpi_store_hour (kpiID int (11) NOT NULL, companyID int (11) NOT NULL, timestamp int (11) NOT NULL, value flotter NOT NULL, clé primaire (kpiID, companyID, timestamp)) MOTEUR = InnoDB DEFAULT charset = UTF8

AFFICHER TABLE STATUS

Nom: kpi_store_hour

Moteur: InnoDB

Version: 10

ROW_FORMAT: Compact

lignes: 4973952

AVG_ROW_LENGTH: 95

Data_Length: 476037120

Max_data_length: 0

Index_length: 0

Data_free: 6291456

auto_increment: NULL

create_time: 04/03/2015 11:14: 06

Update_time: NULL

check_time: NULL

Collation: utf8_general_ci

Checksum: NULL

SELECT * FROM kpi.kpi_store_hour OÙ kpiID = 0 ET COMPANYID = 1 ET timestamp < 1353792707;

Durée/récupération: 0,000 s/0.000 sec

EXPLAIN SELECT * FROM kpi.kpi_store_hour OÙ kpiID = 0 ET CompanyID = 1 ET timestamp < 1353792707;

id: 1

select_type: SIMPLE

tableau: kpi_store_hour

Type

: Gamme

possible_keys: Primaire

clé: PRIMAIRE

key_len: 12

ref: NULL

lignes: 743

supplémentaire: Utilisation où

Answer 1

InnoDB, le PRIMARY KEY est "en cluster" avec les données. Dit différemment, les données sont stockées dans un BTree qui est commandé par le PK. Puisque les deux (data et PK) coexistent, leur taille est comptée en Data_length (476MB) et rien en Index_length. Si vous aviez des clés «secondaires», elles seraient comptées dans Index_length.

La table a 4 champs de 4 octets, donc en théorie une ligne ne devrait occuper que 16 octets. Notez que Avg_row_length est 95. Ceci est dû à

• frais généraux pour chaque colonne
• frais généraux pour chaque rangée
• frais généraux pour BTree
• et certains frais généraux pour la clé primaire.

key_len: 12 - Cela implique que les 3 champs 4 octets du PK ont été utilisés ...

WHERE kpiID = 0 AND companyID = 1 AND timestamp < 1353792707 pourrait rapidement percer dans la BTree à la première ligne avec kpiID = 0 AND companyID = 1, puis balayage jusqu'à timestamp < 1353792707 échoue . Et il a estimé que 743 lignes seraient rencontrées.