Discussion :

[Evocatii]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT champ FROM matable
WHERE champ [???]

Je me demandais comment faire pour sélectionner le champ quelle que soit sa valeur ? Peu importe la valeur du champ, j'aimerais que MySQL me le sélectionne ?

Je sais qu'il suffirait de ne pas mentionner le champ comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT champ FROM matable

Mais j'ai besoin de mentionner ce champ dans la requête afin que MySQL utilise un index-multiple.

Merci beaucoup pour votre aide,
Evocatii

[jeremya]

Tu peux forcer l'utilisation d'un index en l'indiquant explicitement dans la clause FROM.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
tbl_name [[AS] alias]
    [[USE INDEX (key_list)]
      | [IGNORE INDEX (key_list)]
      | [FORCE INDEX (key_list)]]

[Maximil ian]

Salut,

De quoi est composé ton index multiple ?

Pour une requête donnée, MySQL n'utilisera pas un index multiple si la partie gauche de l'index a une valeur indéterminée dans la requête, c'est tout à fait normal. Il serait illusoire de penser qu'on peut forcer l'utilisation de l'index dans un tel cas.

[Evocatii]

Bonjour,

Merci pour vos réponses. Alors pour détailler un peu mon problème (pas évident à expliquer d'ailleurs).

Prenons le cas d'une table de trois champs :

champ1, un entier
champ2, un entier, mais qui n'a que trois valeurs possibles : 1, 2 et 3.
champ3, un entier

Un index-multiple a été placé sur champ1-champ2-champ3.

Donc je peux faire des requête sur : champ1, champ1-champ2 et champ1-champ2-champ3. On est d'accord ?

L'idée serait donc de pouvoir quand même faire des requêtes sur champ1-champ3.

Comment ? De la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT * 
FROM matable 
WHERE champ1 = valeur1 
  AND (champ2 = 1 OR champ2 = 2 OR champ2 = 3)
  AND champ3 = valeur3

Je me trompe où cette requête utilisera quand même l'index multiple sur champ1, champ2 et champ3 ? (A défaut d'une valeur, le champ2 étant utilisé en énumérant les valeurs possibles pour celui-ci.)

Merci beaucoup !
Evocatii

[Maximil ian]

Je me trompe où cette requête utilisera quand même l'index multiple sur champ1, champ2 et champ3 ?

Oui là effectivement ! Mais dans cette requête ça ne serait a priori pas plus performant qu'un seul index sur champ1, et moins performant qu'un index sur champ1 et un sur champ3.

[Evocatii]

Oui là effectivement ! Mais dans cette requête ça ne serait a priori pas plus performant qu'un seul index sur champ1, et moins performant qu'un index sur champ1 et un sur champ3.

Oki merci !

Ah décidemment, quelle galère ces indexes je trouve !

Sinon, tu dis "moins performant qu'un index sur champ1 et un sur champ3". Je croyais que MySQL ne pouvait pas utiliser plus d'un index par requête ? Ou peut-être parlais-tu d'un index sur champ1-champ3 ?

Quoi qu'il en soit, un grand merci pour ton aide ! Je vais essayer de rouver de la documentation à ce sujet, car vraiment pas évident.

Evocatii

[Maximil ian]

Sinon, tu dis "moins performant qu'un index sur champ1 et un sur champ3". Je croyais que MySQL ne pouvait pas utiliser plus d'un index par requête ? Ou peut-être parlais-tu d'un index sur champ1-champ3 ?

Sous MySQL <=4.1 le plus restrictif des 2 index sera utilisé. Sous MySQL 5.0+ le serveur est capable de faire une intersection entre les 2 index.

Sinon effectivement un index sur (champ1, champ3) sera le plus efficace mais il faut mesurer le coût en terme de performances en écriture et d'espace disque occupé si tu cumules plusieurs index.

[Evocatii]

Sous MySQL <=4.1 le plus restrictif des 2 index sera utilisé. Sous MySQL 5.0+ le serveur est capable de faire une intersection entre les 2 index.

Sinon effectivement un index sur (champ1, champ3) sera le plus efficace mais il faut mesurer le coût en terme de performances en écriture et d'espace disque occupé si tu cumules plusieurs index.

Ah exxxxxccceellent !!!

Je ne savais pas pour l'intersection d'index ! Ah c'est sûr, tout semble plus facile à gérer du coup !

http://dev.mysql.com/doc/refman/5.0/...imization.html

Merci Maximilian.

[Evocatii]

Re-bonjour,

J'aurais encore une petite question... Un problème par rapport à la conception de ma table...

La majorité des champs utilisés sont des champs qui ne peuvent prendre que quelques valeurs (par exemple : homme-femme, etc.). Si bien, qu'aucun n'index n'est utilisé. Par exemple, si je mets un index sur le champ "genre" (homme ou femme : donc 50% - 50%), MySQL me fera un scan complet de la table et ignorera l'index (vu que l'index n'est pas assez restrictif et que c'est donc plus rapide pour lui de lire l'ensemble de la table).

Ainsi mes indexes ne servent à rien vu que MySQL choisit de les ignorer. Donc je me retrouve avec plein de critères indexés, mais dans la pratique, MySQL n'en sélectionne aucun.

Ma base de donnée tient le coup, c'est rapide. Mais j'entends, à terme, quand la base sera plus remplie, ça risque de poser de gros problèmes de performance de scanner toute la base pour ne sortir que quelques enregistrements...

Bref, comment gérer ce genre de cas au niveau conceptuel ? Je dois changer et améliorer quoi ?

Bonne fin de journée, merci encore pout tout !
Evocatii

[Maximil ian]

C'est sûr qu'une colonne sexe ne sera pas la plus utile à indexer...
Maintenant ce n'est pas parce que la colonne ne contient que quelques valeurs différentes que l'index ne sera pas utilisé. Si beaucoup de recherches se font sur des valeurs à faible occurrence un index peut être justifié.
Ce n'est pas vraiment un problème de conception mais plutôt une question de sémantique des données à prendre en compte pour indexer la table correctement.

Si tu crains des parcours de table et des jeux de résultats trop gros, il y a toujours possibilité de paginer la recherche avec LIMIT.

[Evocatii]

C'est sûr qu'une colonne sexe ne sera pas la plus utile à indexer...
Maintenant ce n'est pas parce que la colonne ne contient que quelques valeurs différentes que l'index ne sera pas utilisé. Si beaucoup de recherches se font sur des valeurs à faible occurrence un index peut être justifié.
Ce n'est pas vraiment un problème de conception mais plutôt une question de sémantique des données à prendre en compte pour indexer la table correctement.

Si tu crains des parcours de table et des jeux de résultats trop gros, il y a toujours possibilité de paginer la recherche avec LIMIT.

D'accord ça marche !

Et sinon, par exemple, est-ce qu'on pourrait imaginer créer un champ "recherche" qui contiendrait justement tous les critères peu restrictifs comme le sexe, etc. Par exemple, homme/femme = 0 ou 1, ensuite critèreX = 0 ou 1, critèreY = 0 ou 1, etc.

Le champ recherche serait ainsi une concaténation de ces critères peu restrictifs, par exemple 010, 011, etc. pour ensuite utiliser cette table pour des recherches?

Est-ce que ça serait plus adapté niveau performances ? Ou c’est un non-sens et ça revient simplement à dupliquer l’information ?

Bonne soirée,
Evocatii

[Maximil ian]

Ca existe déjà : cf le type SET.

Par contre l'index ne sera utilisé que sur la chaine entière, donc une recherche sur tous les critères (ou le premier avec un %).

[Evocatii]

D'accord, merci !

Sinon, pour en revenir à ce que tu disais :

Si tu crains des parcours de table et des jeux de résultats trop gros, il y a toujours possibilité de paginer la recherche avec LIMIT.

Arrête-moi si je me trompe, mais un LIMIT revient à exécuter la requête mais à ignorer les résultats "hors limite", donc en gros ça ne va rien changer et rien optimiser du tout niveau parcours de table ?

[Maximil ian]

En fait si, dans le cas où un parcours complet de table aurait été fait sans le LIMIT :

If you are selecting only a few rows with LIMIT, MySQL uses indexes in some cases when normally it would prefer to do a full table scan.

et aussi :

If you use LIMIT row_count with ORDER BY, MySQL ends the sorting as soon as it has found the first row_count rows of the sorted result, rather than sorting the entire result. If ordering is done by using an index, this is very fast.

http://dev.mysql.com/doc/refman/5.0/...imization.html