A voir également:
- Problème d'optimisation de requêtes
- Optimisation pc - Guide
- Optimisation découpe panneau gratuit - Télécharger - Outils professionnels
- Optimisation windows 10 - Guide
- Glary Utilities : l'outil référence pour entretenir un PC - Télécharger - Nettoyage
- TweakPower : un outil complet pour optimiser Windows - Télécharger - Nettoyage
4 réponses
Utilisateur anonyme
Modifié par nagashima le 18/02/2014 à 13:29
Modifié par nagashima le 18/02/2014 à 13:29
salut,
tu peux forcer l'index
et juste comme ca, inner join est implicite au join en mysql, et
naga
edit : (date_modif,id_bloc) sera à remplacer par le nom de l'index si je ne m'abuse (que tu n'as pas donné)
tu peux forcer l'index
FROM t_bloc AS B FORCE INDEX (date_modif,id_bloc)
et juste comme ca, inner join est implicite au join en mysql, et
limit 10sera suffisant ;)
naga
edit : (date_modif,id_bloc) sera à remplacer par le nom de l'index si je ne m'abuse (que tu n'as pas donné)
Utilisateur anonyme
Modifié par moukat13 le 18/02/2014 à 14:20
Modifié par moukat13 le 18/02/2014 à 14:20
Bonjour
Tout d'abord merci pour avoir répondu.
Alors très honnêtement je ne suis pas fan du forçage d'index, si l'optimiseur ne l'utilise pas c'est qu'il doit y avoir un soucis dans la structure de la requête qui empêche son utilisation.
De plus même si la forcer peut fonctionner dans les tests, en production et en fonction du nombre d'enregistrement je pourrais rencontrer de gros soucis ;)
Je suis également pas fan du STRAIGHT_JOIN pour les mêmes raisons. Et je voudrais éviter également les requêtes imbriquées qui a mon avis n'aurait pas de sens pour une requête aussi simple.
Généralement je préfère me fier aux choix de l'optimiseur ;)
Donc effectivement je gagne un peu en rapidité avec le FORCE INDEX (3 à 4 fois plus rapide)
et je n'ai plus les USE TEMPORARY et FILESORT,
Mais je craint le pire en prod par la suite ;)
Je suis vraiment pas chaud par le FORCE INDEX désolé :/
En fait il faudrait presque pouvoir faire un index combiné de (id_taxon,date_modif) si j'ai bien compris le fonctionnement de l'optimiseur.
Mais le probleme c'est qu'ils appartiennent à 2 tables différentes :/
Mais c'est quand même dingue qu'une jointure de base n'arrive pas à s'optimiser.
par contre évidemment dès que je retire le order by tout est ok, le explain et le temps d'exécution.
Pour le limit j'ai besoin de le définir de la sorte pour la gestion de la pagination ;)
Tout d'abord merci pour avoir répondu.
Alors très honnêtement je ne suis pas fan du forçage d'index, si l'optimiseur ne l'utilise pas c'est qu'il doit y avoir un soucis dans la structure de la requête qui empêche son utilisation.
De plus même si la forcer peut fonctionner dans les tests, en production et en fonction du nombre d'enregistrement je pourrais rencontrer de gros soucis ;)
Je suis également pas fan du STRAIGHT_JOIN pour les mêmes raisons. Et je voudrais éviter également les requêtes imbriquées qui a mon avis n'aurait pas de sens pour une requête aussi simple.
Généralement je préfère me fier aux choix de l'optimiseur ;)
Donc effectivement je gagne un peu en rapidité avec le FORCE INDEX (3 à 4 fois plus rapide)
SELECT B.date_modif FROM t_bloc AS B FORCE INDEX (idx_date_idbloc)
INNER JOIN t_taxon_bloc AS TB
ON (TB.id_bloc=B.id_bloc)
WHERE TB.id_taxon=44
order by B.date_modif DESC
limit 0,10
et je n'ai plus les USE TEMPORARY et FILESORT,
Mais je craint le pire en prod par la suite ;)
Je suis vraiment pas chaud par le FORCE INDEX désolé :/
En fait il faudrait presque pouvoir faire un index combiné de (id_taxon,date_modif) si j'ai bien compris le fonctionnement de l'optimiseur.
Mais le probleme c'est qu'ils appartiennent à 2 tables différentes :/
Mais c'est quand même dingue qu'une jointure de base n'arrive pas à s'optimiser.
par contre évidemment dès que je retire le order by tout est ok, le explain et le temps d'exécution.
Pour le limit j'ai besoin de le définir de la sorte pour la gestion de la pagination ;)
L'optimiseur n'est pas top dans tous les cas, ca reste un algo générique qui, pour une majeur partie des cas, permettra d'obtenir le choix le plus judicieux (optimisé donc). Mais comme tout élément générique, ils ne peux pas être fonctionnel dans 100% des cas. S'appuyer totalement/aveuglement sur l'optimiseur est une erreur (un peu comme si je te disais que tu peux à 100% te fier à windows, ou un linux, quelque soit ton matériel => l'os se veut multi-plateforme mais tu peux te retrouver en face de cas).
Pour ma part, j'utilise en prod le force index car je suis justement confronté à certains cas => je n'ai eu aucuns soucis de concordance de données ou quoi que ce soit, par contre mes temps de traitement sont bien meilleur (à hauteur de 80% de gain de temps et donc moins de charge sur le serveur).
Après, bien sûr forcer l'index reste quelquechose que l'on va faire rarement, mais parfois il faut un peu guider ton requêteur pour qu'il prenne le bon chemin :)
faire un indexe combiné revient simplement à faire une table de concordance (que tu indexera) ou encore une table temporaire mais je pense pas que ca soit terrible dans ton cas.
naga
Pour ma part, j'utilise en prod le force index car je suis justement confronté à certains cas => je n'ai eu aucuns soucis de concordance de données ou quoi que ce soit, par contre mes temps de traitement sont bien meilleur (à hauteur de 80% de gain de temps et donc moins de charge sur le serveur).
Après, bien sûr forcer l'index reste quelquechose que l'on va faire rarement, mais parfois il faut un peu guider ton requêteur pour qu'il prenne le bon chemin :)
faire un indexe combiné revient simplement à faire une table de concordance (que tu indexera) ou encore une table temporaire mais je pense pas que ca soit terrible dans ton cas.
naga
Utilisateur anonyme
Modifié par moukat13 le 18/02/2014 à 15:40
Modifié par moukat13 le 18/02/2014 à 15:40
Je te remercies, malheureusement dans mon cas les gains gagnés (3 a 4 fois plus rapide) ne sont à mon avis pas encore suffisant. Etant donné le peu d'enregistrement dans ma phase de test je devrais être au moins 10 fois plus rapide voir plus ;)
On m'avait proposé une solution suivante sur un autre forum :
Ce qui semble donné le même résultat que le FORCE INDEX.
Là pareil j'étais moyennement chaud sur la requete imbriquée, et difficile de voir si les gains ne vont pas se transformer en perte en prod.
D'autant plus qu'il est possible qu'en fin de compte je sois obligé ensuite de passer de EXISTS à IN tout dépendra du nbr d'enregistrements de la sous requete.
Que conseillerais tu le plus, forcer l'index ou la requête imbriquée avec EXISTS?
En fait il semblerait que ce qui perturbe dans ma requête principale c'est le WHERE TB.id_taxon=44, qui pertube mon order by date et empêche l'utilisation de l'index :/
Si j'ai bien compris la requête imbriquée dissocie la requête principale de celle imbriquée ce qui fait qu'il ne reste plus qu'id_bloc et date_modif dans la requête principal d'où l'utilisation de l'index combiné.
J'avais vraiment espéré qu'en ajoutant une petite clause dans le WHERE j'aurais réglé le soucis mais j'ai pas trouvé en tout cas.
je suis peut être condamné à utiliser la requête imbriquée, le force index (même si les gains ne sont pas encore suffisant) ou a avoir des requêtes trop gourmandes :/
On m'avait proposé une solution suivante sur un autre forum :
SELECT B.id_bloc
FROM t_bloc AS B
WHERE EXISTS (
SELECT 1 FROM t_taxon_bloc AS TB
WHERE TB.id_taxon=44 AND TB.id_bloc=B.id_bloc
)
ORDER BY B.date_modif DESC
Ce qui semble donné le même résultat que le FORCE INDEX.
Là pareil j'étais moyennement chaud sur la requete imbriquée, et difficile de voir si les gains ne vont pas se transformer en perte en prod.
D'autant plus qu'il est possible qu'en fin de compte je sois obligé ensuite de passer de EXISTS à IN tout dépendra du nbr d'enregistrements de la sous requete.
Que conseillerais tu le plus, forcer l'index ou la requête imbriquée avec EXISTS?
En fait il semblerait que ce qui perturbe dans ma requête principale c'est le WHERE TB.id_taxon=44, qui pertube mon order by date et empêche l'utilisation de l'index :/
Si j'ai bien compris la requête imbriquée dissocie la requête principale de celle imbriquée ce qui fait qu'il ne reste plus qu'id_bloc et date_modif dans la requête principal d'où l'utilisation de l'index combiné.
J'avais vraiment espéré qu'en ajoutant une petite clause dans le WHERE j'aurais réglé le soucis mais j'ai pas trouvé en tout cas.
je suis peut être condamné à utiliser la requête imbriquée, le force index (même si les gains ne sont pas encore suffisant) ou a avoir des requêtes trop gourmandes :/
Utilisateur anonyme
18 févr. 2014 à 17:02
18 févr. 2014 à 17:02
Alors en fait en effectuant d'autres tests avec le force index ou la requête imbriquée, lorsque j'avais que 200 enregistrements répondant aux critères c'était moins performant (seulement 3-4 dois plus rapide) que lorsque j'ai plus de 1000 enregistrements (10 fois plus rapide).
Par conséquent il semblerait que forcer l'index ou utiliser la requête imbriquée soit vraiment plus performant que ma requête de base lorsque j'ai plus d'enregistrements. Difficile encore de comprendre pourquoi :)
Par conséquent il semblerait que forcer l'index ou utiliser la requête imbriquée soit vraiment plus performant que ma requête de base lorsque j'ai plus d'enregistrements. Difficile encore de comprendre pourquoi :)
salut,
tu as probablement déjà donné la raison : l'order by. Je connais pas le fond de mySQL, je suis juste utilisateur, mais j'ai aussi remarqué ce genre de chose (une fois que j'ai connu le force index, ce qui n'était pas le cas au départ^^). L'optimiseur connait quelques lacunes (ce qui est normal vu qu'il se veut multi schéma) et il faut donc parfois l'aiguiller un peu.
Pour tester, il faudrai que tu mette ta requête en sous requête, sans l'order by qui sera fait avec la requête mère :
Si tu joue la requête, je pense que cette fois l'index choisi sera le bon (histoire de voir si le soucis est sur l'order by ou non).
tu as probablement déjà donné la raison : l'order by. Je connais pas le fond de mySQL, je suis juste utilisateur, mais j'ai aussi remarqué ce genre de chose (une fois que j'ai connu le force index, ce qui n'était pas le cas au départ^^). L'optimiseur connait quelques lacunes (ce qui est normal vu qu'il se veut multi schéma) et il faut donc parfois l'aiguiller un peu.
Pour tester, il faudrai que tu mette ta requête en sous requête, sans l'order by qui sera fait avec la requête mère :
select *
from (
-- TA REQUETE
) as sub
order by sub.date_modif DESC
Si tu joue la requête, je pense que cette fois l'index choisi sera le bon (histoire de voir si le soucis est sur l'order by ou non).
