Discussion :

[Romalafrite]

Bonjour à tous.

Grosso modo j'ai une grosse requête qui fait ceci :

SELECT les commandes ORDER BY date DESC LIMITE AUX 20 premiers

sauf que comme il y a des milliers de résultats, il prend l'ensemble des résultats, les retourne puis ensuite filtre les 20 premiers, ce qui a pour conséquence de faire une requête extrêmement longue (7 secondes).

Comment optimiser ça et où placer mes index (on m'a parlé d' "index composé" ?)

Vous pourrez voir le début de notre conversation à cette adresse :

http://www.webrankinfo.com/forums/vi...c.php?p=610321

Mais il est vrai que WRI est plus une communauté de référenceurs que de férus de MySQL.

Merci de votre aide, donc.

[avogadro]

et si tu fais une view avec les 20 premieres résultats, la view est créé une seul fois, et apres tu n'a plus qu'a l'afficher, et des que tu modifies des infos sur la table auquel elle fait référence elle se met toute seul a jour (je crois)

Pour créer une vue vous devez utiliser CREATE VIEW


CREATE [OR REPLACE] VIEW
[FORCE|NOFORCE] viewname
[(alias)]
AS subquery
[WITH CHECK OPTION [CONSTRAINT constraint]
[WITH READ ONLY [CONSTRAINT constraint];

OR REPLACE: Recrée la vue si elle existe.

FORCE: Crée une vue même si la table n’existe pas.

NOFORCE: Crée une vue seulement si la table existe.

Viewname: Nom de la vue.

Alias: Spécifie des noms pour les expressions sélectionnées

Subquery: La requête SELECT complète.

WITH CHECK OPTION: Spécifie que seul des lignes accessibles par la vue peuvent être mis à
jour ou inserés.

Constraint: Est le nom donné à la contrainte CHECK OPTIONS.

WITH READ ONLY: Assure qu’aucune opération DML ne peut pas être effectuée.


Exemple:

SQL> CREATE OR REPLACE VIEW empvu
2 AS
3 SELECT empno, ename,sal
4 FROM emp
5 WHERE deptno=30;

[Romalafrite]

et si tu fais une view avec les 20 premieres résultats, la view est créé une seul fois, et apres tu n'a plus qu'a l'afficher, et des que tu modifies des infos sur la table auquel elle fait référence elle se met toute seul a jour (je crois)

D'après ce que tu me dis, c'est l'idéal, vraiment génial.

Où est-ce que je place cette requête ? lors d'une modif de la base ou juste je la crée une fois ?

[avogadro]

D'après ce que tu me dis, c'est l'idéal, vraiment génial.

Où est-ce que je place cette requête ? lors d'une modif de la base ou juste je la crée une fois ?

normalement tu la crées une seule fois la view parce que c'est fait pour les infos souvent demandés, donc je pense que si tu fais des modifications sur la table auquelle la vue fait référence, la vue se met a jour toute seul comme les données sont liées directement a la table de référence. C'est a tester, sinon je ne vois pas trop l'intéret d'une view ^^

Puis apres si tu utilises un site en php avec phpmyadmin tu lance ta requette pour créer la view directement dans phpmyadmin et sur le site tu fais les requettes pour afficher la vue !

C'est un début d'idée, a approfondir...

[jeca]

Bonjour,

Extrait du manuel de référence mysql :

Si vous utilisez LIMIT # avec la clause ORDER BY, MySQL va arrêter de trier dès qu'il a trouvé la première # au lieu de trier toute la table.

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

[Romalafrite]

Bonjour,

Extrait du manuel de référence mysql :


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

Rien compris, en fait, j'ai trouvé une solution convenable en limitant la recherche aux X dernières commandes (WHERE id_commande > (max_id_commande - X))

[cadoudal56]

Oui ou alors il existe une autre possibilité....
Si tu connais ta fréquence de commande (genre x commande tous les jours ou tous les mois, tu utilise un BETWEEN
WHERE date BETWEEN xxx TO xxx

Et tu limites toujours sur les 20 premiers...

@+
cadou

[Sivrît]

Pour l'utilisation d'une vue j'ai peur que lorsqu'on l'appelle la requête qui la définie soit exécutée, ce qui nous ramènerait au point de départ... cela dit je connais mal le fonctionnement des vues.


Je pense qu'un indexe sur le champ 'date' devrait régler l'affaire. Comme ça le tri est déjà fait et le limit devient trivial. Un truc comme :

Code :

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

CREATE INDEX MonIndexSurLesDates ON MaTable(date);

[Romalafrite]

Pour l'utilisation d'une vue j'ai peur que lorsqu'on l'appelle la requête qui la définie soit exécutée, ce qui nous ramènerait au point de départ... cela dit je connais mal le fonctionnement des vues.


Je pense qu'un indexe sur le champ 'date' devrait régler l'affaire. Comme ça le tri est déjà fait et le limit devient trivial. Un truc comme :

Code :

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

CREATE INDEX MonIndexSurLesDates ON MaTable(date);

je l'ai déjà ça mais ça n'a pas fait grand chose malheureusement..

[Sivrît]

Il aurait peut-être mieux vallu copier la requête de l'autre forum, parce que tel que c'est dit dans le message initial ça semble assez trivial.

J'ai peur que le 'etat<>-1' ne pose problème. Le mieux serait de commencer avec une requête qui ne contient que la première table et de jouer avec 'EXPLAIN' pour s'assurer que l'on utilise bien un index, quitte à indexer (etat, date) et (date, etat) (le deuxième me semble plus susceptible de fonctionner). Il y a dans la doc de mysql un mot clef pour forcer l'utilisation d'un index; ce serait peut-être à tester en désepoir de cause. Il est possible que la version de MysqL influence l'optimisation des LIMIT/ORDER BY.

Si ça passe il sera temps de rajouter les jointures une par une en veillant à ce que chaque étape lie bien via un indexe (ce devrait être assez facile car les liaisons sont simples). Si possible les 'LEFT JOIN' seraient à éviter car bien plus lents que de simples 'JOIN'.


Le lien pour les vues devait être pour moi Mais tel que je vois leur fonctionnement elles ne vont pas résoudre le problème de vitesse, à moins peut être que les tables concernées ne soient que rarement mises à jour.

[Romalafrite]

Il aurait peut-être mieux vallu copier la requête de l'autre forum, parce que tel que c'est dit dans le message initial ça semble assez trivial.

J'ai peur que le 'etat<>-1' ne pose problème. Le mieux serait de commencer avec une requête qui ne contient que la première table et de jouer avec 'EXPLAIN' pour s'assurer que l'on utilise bien un index, quitte à indexer (etat, date) et (date, etat) (le deuxième me semble plus susceptible de fonctionner). Il y a dans la doc de mysql un mot clef pour forcer l'utilisation d'un index; ce serait peut-être à tester en désepoir de cause. Il est possible que la version de MysqL influence l'optimisation des LIMIT/ORDER BY.

Si ça passe il sera temps de rajouter les jointures une par une en veillant à ce que chaque étape lie bien via un indexe (ce devrait être assez facile car les liaisons sont simples). Si possible les 'LEFT JOIN' seraient à éviter car bien plus lents que de simples 'JOIN'.


Le lien pour les vues devait être pour moi Mais tel que je vois leur fonctionnement elles ne vont pas résoudre le problème de vitesse, à moins peut être que les tables concernées ne soient que rarement mises à jour.

Merci.