Commentaires sur : Comment réécrire une requête SQL ? Partie 1

Par : stephane

stephane — Mon, 25 Oct 2010 13:33:27 +0000

Si tu connais Maatkit, tu peux essayer d’utiliser mk-query-advisor. Si tu ne connais pas, j’en parlerai dans un prochain post

Par : gene69

gene69 — Thu, 21 Oct 2010 23:46:35 +0000

est-ce qu’il existe des outils qui permettent de réécrire la requete automatiquement?

Je veux dire, lorsqu’on a écrit une requete avec un résultat juste avec une écriture complexe, je cherche un outil qui me signale automatiquement les simplifications à faire.

Je suis certain que c’est possible pour l’avoir fait à la main et pour avoir vu MS SQL-Server le faire, cependant, je me demande si ça existe pour MySql.

Par : stephane

stephane — Thu, 03 Dec 2009 16:47:38 +0000

Oui dans le cas des clauses OR, l’optimiseur est embêté car il ne peut utiliser qu’un seul index à la fois…index qui ne sera donc pas pertinent pour l’ensemble des OR. D’où le full table scan.

En utilisant des UNION comme tu le dis, on évite les full table scan si les colonnes sur lesquelles portent les OR ont des index. En contrepartie, on crée une table temporaire à cause des UNION.

A partir de MySQL 5.0, il n’y a en principe plus ce problème car l’optimiseur sait combiner dans ce cas particulier plusieurs index. On voit alors dans le EXPLAIN un affichage du type :
type: index_merge
key: idx_pw,idx_ph,idx_pc
…
Extra: Using sort_union(idx_pw,idx_ph,idx_pc); Using where

Ca pourra être l’objet d’un prochain post !

Par : Xavier

Xavier — Mon, 30 Nov 2009 11:53:49 +0000

Dans le même genre, il y a les clauses OR:

select titi, tata from table where cond1 or cond2 or cond3;

Visiblement, on peut gagner en réécrivant la requête comme suit:

select titi, tata from table where cond1 UNION \
select titi, tata from table where cond2 UNION \
select titi, tata from table where cond3;

Visiblement, mysql est trop vite tenté par un full table scan sinon.

Par : Arnaud

Arnaud — Fri, 27 Nov 2009 07:39:33 +0000

Sympa ton astuce, à garder en mémoire !