Ces indices sont redondants MySQL?

Considérez le tableau suivant.



Est-il intéressant d'avoir des indices de ces deux dernières KEY là?

Souhaitez-requêtes qui ont des clauses WHERE qui dépendent de ces colonnes à usage unique l'indice de colonne unique, auraient-ils utiliser les index multi-colonne, auraient-ils ne pas utiliser quoi que ce soit en raison de l'astérisque (*) sélection de la colonne?

Quelques réflexions.

Un caractère unique entre des paires category_id et item_id est nécessaire pour qu'il n'y ait pas de lignes redondantes. J'ai donc besoin soit d'une clé PRIMARY ou UNIQUE qui utilise ces deux colonnes.

Je pourrais tomber insert_order et utiliser la clé unique de la clé primaire. Si je fais ce que, la capacité d'avoir une sorte de chronologie appliquée aux lignes devient plus compliqué que je soin de réfléchir.

Selon le manuel , Ma clef unique offre en soi un index sur la colonne category_id seul, ainsi que sur les deux colonnes ensemble à cause de la "plus à gauche de la règle".

Je pourrais supprimer l'index seule colonne sur category_id et comptent sur la clé multi-colonne de la colonne category_id, mais la puissance du multi-colonne de clé est susceptible d'être proche si elle n'est pas la même que la cardinalité de la clé primaire, ou , la taille de l'ensemble du tableau, tandis que le cardinal de la colonne unique INDEX category_id doit toujours être inférieure car elle est de taille limitée au nombre de catégories.

Touches sont plus petites, les recherches plus rapidement. MySQL semble favorable touches seule colonne, lorsque les deux sont présents, si je comprends que le droit de page de manuel.

Parce qu'il est possible d'associer un item_id avec category_ids multiples, l'index sur item_id seul rend les recherches plus rapidement lorsqu'il s'agit de gérer les associations entre un élément et une catégorie. En raison de la "plus à gauche de la règle", l'indice UNIQUE dans la table ne peut pas être utilisé pour item_id dans des situations où Im recherchant l'item_id et je veux savoir toutes les catégories y sont associés.

Ok theres mon raisonnement.
Suis-je rien oublier?

Eh bien, ce n'est certainement intéressant.

Ive a obtenu la requête suivante qui utilise cette table les relations lors de l'affichage des pages de catégories.



Car une catégorie peut être assignée comme un pare pas la catégorie, Im récupérer le category_id de toute catégorie de l'actuelle catégorie fixé comme pare pas devant cette requête et qui me donne soit un "category_id = N" ou "category_id IN (N, N ) "pour" $ t-> category_sql "en fonction des catégories combien il y êtes. Cela me permet d'avoir pare pas des catégories que les deux ont leurs propres éléments, et comprendra les éléments de leurs enfants immédiats dans leurs pages de catégorie.

La partie intersting est que lorsque vous l'expliquer à cette requête, je vois les valeurs supplémentaires "Using where; Utiliser filesort". D'après ce que je comprends "en utilisant filesort" est de mauvaises nouvelles. Il y avait une clause DISTINCT sur cette requête, mais qu'il était à l'origine "en utilisant nouvelles temporaire" qui est mauvais aussi.

Cependant, quand je dépose que la clause ORDER BY de la requête, mes tours supplémentaires dans "Utilisation d'Index", ce qui signifie qu'il n'a même pas de regarder les lignes de données, et elle retourne toujours le même ordre. Im guessing cause de cette clé insert_id PRIMAIRE.

La requête prend également note de la clé unique à la fois et l'indice category_id unique comme les clés possibles, sa décision d'utiliser la touche seule colonne par les regards de celle-ci, bien que le key_len étant à 2 dans la sortie de cette table m'a confus.

Vous me confondez aussi!

Blog post Nice "Nous comprenons en arrière», thats pretty trippy, vous êtes probablement trop bon! haha.

key_len est la longueur de la ligne d'index, en octets, et non le nombre de colonnes dans l'index. Thats ce qui m'avait confus.