Comment puis-index MySQL de travail?

La première chose que vous devez savoir est que les index sont un moyen d'éviter la numérisation de l'intégralité de la table pour obtenir le résultat que vous recherchez.

Il existe différents types d'index et ils sont mis en œuvre dans la couche de stockage, donc il n'y a pas de standard entre eux et ils dépendent aussi du moteur de stockage que vous utilisez.

InnoDB et le B+index d'Arborescence

Pour InnoDB, le plus commun type d'index est le B+Arbre en fonction de l'indice, qui stocke les éléments dans un ordre trié. Aussi, vous n'avez pas accès à la "vraie" table pour obtenir les valeurs indexées, ce qui rend votre requête en retour beaucoup plus rapide.

Le "problème" à propos de ce type d'index est que vous avez à la requête de la plus à gauche de la valeur à l'index. Donc, si votre index a deux colonnes, dire le nom et le prénom, l'ordre vous interroger ces champs questions beaucoup.

Donc, d'après le tableau suivant:

CREATE TABLE person (
    last_name VARCHAR(50) NOT NULL,
    first_name VARCHAR(50) NOT NULL,
    INDEX (last_name, first_name)
);

Cette requête devrait profiter de l'index:

SELECT last_name, first_name FROM person
WHERE last_name = "John" AND first_name LIKE "J%"

Mais la suivante ne serait pas

SELECT last_name, first_name FROM person WHERE first_name = "Constantine"

Parce que vous êtes à l'interrogation de la first_name colonne premier et ce n'est pas la colonne de gauche de l'index.

Ce dernier exemple est encore pire:

SELECT last_name, first_name FROM person WHERE first_name LIKE "%Constantine"

Parce que maintenant, vous allez comparer la partie droite de la droite du champ de l'indice.

L'index de hachage

C'est un autre type d'index qui, malheureusement, seule la mémoire backend prend en charge. Il est rapide comme l'éclair, mais seulement utile pour plein de recherches, ce qui signifie que vous ne pouvez pas l'utiliser pour des opérations comme >, < ou LIKE.

Depuis il ne fonctionne que pour la mémoire backend, vous n'aurez probablement pas l'utiliser très souvent. Les principaux cas je pense dès maintenant est celui que vous créez une table temporaire dans la mémoire, avec un ensemble de résultats à partir d'un autre de sélectionner et d'effectuer un grand nombre d'autres sélectionne dans cette table temporaire à l'aide de hachage index.

Si vous avez un gros VARCHAR domaine, vous pouvez "imiter" l'utilisation d'un index de hachage lors de l'utilisation d'un B-Arbre, par la création d'une autre colonne et l'enregistrement d'un hachage de la grande valeur. Disons que vous êtes le stockage d'une url dans un champ et les valeurs sont assez grandes. Vous pouvez également créer un champ de type entier appelé url_hash et l'utilisation d'une fonction de hachage comme CRC32 ou toute autre fonction de hachage hash de l'url lorsque vous l'insérez. Et puis, quand vous en avez besoin pour la requête de cette valeur, vous pouvez faire quelque chose comme ceci:

SELECT url FROM url_table WHERE url_hash=CRC32("http://gnu.org");

Le problème avec l'exemple ci-dessus est que, depuis la CRC32 fonction génère une toute petite table de hachage, vous vous retrouverez avec beaucoup de collisions dans les valeurs de hachage. Si vous avez besoin des valeurs exactes, vous pouvez résoudre ce problème en procédant comme suit:

SELECT url FROM url_table 
WHERE url_hash=CRC32("http://gnu.org") AND url="http://gnu.org";

Il est toujours intéressant de hachage des choses, même si le nombre de collision est élevé cause vous n'aurez qu'à effectuer la comparaison (le fil) contre la répétition de hachages.

Malheureusement, en utilisant cette technique, vous avez encore besoin de frapper la table de comparer les url champ.

Envelopper

Certains faits que vous pourriez envisager, chaque fois que vous voulez parler de l'optimisation:

1. Comparaison des entiers est plus rapide que la comparaison de chaînes de caractères. Il peut être illustré avec l'exemple sur l'émulation de l'index de hachage dans InnoDB.

2. Peut-être, en ajoutant des étapes dans un processus rend plus rapide, pas plus lent. Il peut être illustré par le fait que vous pouvez optimiser une SELECT en les divisant en deux étapes, en faisant le premier stocker des valeurs dans une nouvelle table en mémoire, et ensuite exécuter le plus lourd des requêtes sur cette seconde table.

MySQL a d'autres indices de trop, mais je pense que le B+Arbre est le plus utilisé jamais et le hachage est une bonne chose à savoir, mais vous pouvez trouver d'autres dans la Documentation de MySQL.

Je vous recommande fortement de lire la "Haute Performance MySQL", le livre, la réponse ci-dessus est certainement basé sur son chapitre sur les index.

Prendre un coup d'oeil à ce lien: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Comment ils fonctionnent est trop large d'un sujet à couvrir en une SORTE de post.

Ici est l'une des meilleures explications des indices que j'ai vu. Malheureusement, il est pour SQL Server et non MySQL. Je ne suis pas sûr de la façon similaire, les deux sont...