Supposons que j'ai une table de base de données avec des colonnes A, B et c. Je prévois de faire des requêtes sur les trois colonnes, mais je ne suis pas sûr de quelles colonnes en particulier je interrogee. Il y a suffisamment de lignes dans la table qu'un indice accélère immensément la recherche, mais il est faux de faire toutes les permutations d'index possibles (comme ceci): est une meilleure façon de gérer ce problème? (Il est très possible que je sois simplement indexé A, B, C seul, car cela réduira rapidement le nombre de rangées rapidement, mais je me demande s'il y a une meilleure façon.) Si vous avez besoin d'exemples plus concrets, dans les données de la vie réelle, les colonnes sont du code de ville, d'état et postal. En outre, j'utilise une base de données MySQL.
5 Réponses :
dans MS SQL L'index "A, B, C" vous couvrira pour des scénarios "A"; "un B"; et "a, b, c". Donc, vous n'auriez besoin que des index suivants: Je ne sais pas si MySQL fonctionne de la même manière, mais je suppose donc.
C'est la bonne réponse. MySQL fonctionne de la même manière, et cette technique s'appelle "Préfixing le plus à gauche". Dans le manuel MySQL à dev.mysql.com/doc/refman /5.0/fr/mysql-indexes.html : "Si la table a un index de plusieurs colonnes, tout préfixe le plus à gauche de l'index peut être utilisé par l'optimiseur pour trouver des lignes. Par exemple, si vous avez trois -Column index sur (Col1, Col2, Col3), vous avez des capacités de recherche indexées sur (COL1), (COL1, COL2) et (COL1, COL2, COL3) ".
Hmm, j'aurais dû savoir ceci. ;) Très génial, je vais donner cela un coup de feu.
Vous pourriez également avoir besoin d'un, c, mais cela dépend de vos questions. Vous aurez peut-être également besoin de l'index individuel pour couvrir le scénario ou le scénario mentionné par Andriyev, pas sûr.
L'index "A, B, C" vous couvre-t-il pour "A, C"?
Plus les index que vous créez, plus votre performance sera touchée lors de la mise à jour et de la suppression des opérations. Parce que l'index lui-même pourrait être mis à jour.
Oui, vous pouvez utiliser des index multiples. Quelque chose comme Ce type d'index IE Ind1 vous aidera sûrement à des requêtes telles que de même, Ind2 aidera vous dans des requêtes comme mais ces index ne seront pas utilisés si la requête est quelque chose comme ici vous aurez besoin d'index séparés sur A, B et c. Donc, au lieu d'avoir tant d'index, je suis d'accord avec ce que John a dit, c'est-à-dire avoir des index sur A, B, C et si vous sentez que votre La charge de travail couvre plus de requêtes multi-colonnes, vous pouvez ensuite passer aux index multi-colonnes. acclamations
Ce tableau est rarement mis à jour, de sorte que cela ne me préoccupe pas si la mise à jour est lente.
Étant donné que vos colonnes sont en réalité du code de la ville, de l'état et du zip, je suggérerais que les index suivants:
index (ZipCode) Si je suis correct, Les codes postaux ne sont pas dupliqués à travers les États-Unis. Il est donc inutile d'ajouter des informations de ville ou d'état à l'indice, car ils auront la même valeur pour tous les codes postaux. Par exemple, 90210 est toujours Los Angeles, Ca. Index (Ville (5)) ou Index (Ville (5)), État) < / p> Ceci est juste un index sur les cinq premières lettres du nom de la ville. Dans de nombreux cas, cela sera suffisamment précis que l'état indexé ne fournirait aucun filtrage utile. E.G., 'Los A' sera presque certainement des enregistrements de Los Angeles, env. Peut-être qu'il y a une autre petite ville aux États-Unis commençant par "Los A", mais il y aura si peu de disques qu'il ne vaut pas la peine d'encombrer l'index avec des données d'état. D'autre part, certains noms de villes apparaissent dans de nombreux États (Springfield vient à l'esprit), donc dans ces cas, il est préférable d'avoir également l'état de l'État. Vous devrez déterminer pour vous-même quel indice est le plus adapté à votre ensemble de données. En cas de doute, j'irais avec le deuxième index (ville et état). index (état, sort_field ) Etat est un indice assez large (très probablement NY et CA seuls auront seulement 30% des enregistrements). Si vous planifiez l'affichage de cette information à l'utilisateur, dites 30 enregistrements à la fois, vous auriez une requête terminée dans pour faire que Query Efficace, vous devez inclure la colonne de tri de l'indice d'état. Donc, si vous affichez des pages commandées par nom de famille (en présumant que vous avez cette colonne), vous utiliseriez Index (State, Nom (3)) , sinon MySQL doit trier Tout < / strong> des disques 'NY' avant qu'il ne puisse vous donner le 30 que vous voulez.
Vos informations sur les codes postaux ne sont pas strictement correctes. De nombreux codes postaux ont plus d'un "nom de lieu acceptable". Par exemple, "Hollywood, CA" est un nom d'endroit acceptable pour 90028, même si Hollywood n'est qu'un district de Los Angeles et non une ville réelle. Le "nom de lieu par défaut" pour 90028 est en fait "Los Angeles, CA". De plus, parfois deux villes ou portions de deux villes tomberont dans le même code postal. Il est vrai que chaque code postal a exactement un «nom de lieu par défaut», mais vous ne pouvez pas compter sur cela pour les données saisies par l'utilisateur.
Tant qu'il y ait (dans la plupart des cas) pas plus de deux ou trois noms de lieu pour chaque code postal, l'index ira toujours bien.
Je ne sais pas quels sont les pourcentages, mais mon code postal a quatre noms admissibles. Et je connais d'un autre qui a aussi quatre.
Cela dépend de votre requête SQL.
index (A, B, C) est différent de index (B, C, A) ou index (A, C, B)
Pour utiliser des index pour toutes les conditions d'égalité possibles sur les colonnes Voir cet article dans mon blog pour des explications détaillées: p> Vous pouvez également lire le strict mathématique Preuve forte> par russes mathématicien On peut, cependant, obtenir des performances décentes avec moins d'index en utilisant Les techniques suivantes: p> si les colonnes N code>, vous aurez besoin de C ([N / 2], N) code> index, c'est-à-dire n ! / ([N / 2]! * (N - [N / 2])!) Code>
égor timoshenko code> ( Mise à jour: STRY> en anglais). P> col1 code>, col2 code> et col3 code> sélectif, puis cette requête p> SELECT *
FROM mytable
WHERE col1 = :value1
AND col2 = :value2
AND col3 = :value3