Optimisation de requête et index

[Hypnocrate]

Bonjour,
Je me retrouve avec ce genre de requête que je dois optimiser:

Code :

1
2
 
SELECT * FROM T WHERE c1 = 5448 AND c2 = 2 AND c3 IN (541784,69854,515074, ...)

le IN du c3 contient plusieurs milliers d'entrées.

Pour le moment j'ai l'index suivant:

Code :

1
2
 
CREATE INDEX IDX_T ON T (c3,c1,c2)

L'index commence par la colonne du IN donc.

Mais la requête prend encore trop de temps.

Je me demandais si il ne serait mieux de créér un index de ce genre:

Code :

1
2
 
CREATE INDEX IDX_T ON T (c1,c2,c3)

Donc en mettant la colonne du IN à la fin de l'index.
Je suis également à l'écoute d'éventuelles autres idées qui pourrait optimiser cette requête.

Je précise que je ne peux pas trop tester car je ne suis pas admin de la base.

[Nudger]

De quel SGBD s'agit-il ?
L'optimisation d'un code SQL dépend beaucoup du SGBD.
Plusieurs pistes d'amélioration sont envisageable.

Par ailleurs, ne pas avoir les droits admin sur une base n'empêche pas en générale d'utiliser des tables temporaires et de les indexer.

[CinePhil]

D'où provient cette liste de plusieurs milliers de nombres ?

L'idéal serait de faire une table, fut-elle temporaire, contenant en une seule colonne tous ces nombres à rechercher, d'indexer cette colonne puis de faire une jointure avec la table temporaire.

Si cette solution est impossible, dans la mesure où il y a un index sur c3, peut-être qu'en triant la liste dans l'ordre ascendant accélérerait un peu les choses.

[Hypnocrate]

De quel SGBD s'agit-il ?

Il s'agit de DB2.

D'où provient cette liste de plusieurs milliers de nombres ?

L'idéal serait de faire une table, fut-elle temporaire, contenant en une seule colonne tous ces nombres à rechercher, d'indexer cette colonne puis de faire une jointure avec la table temporaire.

Si cette solution est impossible, dans la mesure où il y a un index sur c3, peut-être qu'en triant la liste dans l'ordre ascendant accélérerait un peu les choses.

C'est une liste renvoyée par une fonction java.
Cette fonction construit la liste à partir d'une requête SQL.
J'ai bien essayé d'injecter cette requête dans la requête principale en faisant quelque chose de ce genre:

Code :

SELECT * FROM T WHERE c1 = 5448 AND c2 = 2 AND c3 IN (SELECT id FROM T2 WHERE ...)

Mais au final c'est encore plus lent.
Je vais essayer de trier au préalable cette liste, ça me parait pas bête comme idée. Je vous tiens au courant lundi.

[CinePhil]

Tu as besoin d'apprendre le SQL, et notamment les jointures !

Code :

1
2
3
4
5
SELECT * 
FROM T 
INNER JOIN T2 ON T2.id = t.c3
WHERE c1 = 5448 
  AND c2 = 2

[punkoff]

Sinon, pour la question initial le 2eme index devrait mieux gérer la situation.

Simplement car tu aurai une sélectivité beaucoup plus réduite pour traiter ta clause IN.

Après reste à voir ton select, car avec un "select *" DB2 pourra partir sur un scanage de table direct s'il évalue que tu vas ramener plus de 15-20% des enregistrement totale de ta table.

[Hypnocrate]

Envoyé par CinePhil

Tu as besoin d'apprendre le SQL, et notamment les jointures !

Code :

OK mais au final, le plan de requête est le même non?
Il va devoir passer en revue tous les c3 qui sont dans la table/liste.

Envoyé par punkoff

Sinon, pour la question initial le 2eme index devrait mieux gérer la situation.

Simplement car tu aurai une sélectivité beaucoup plus réduite pour traiter ta clause IN.

Après reste à voir ton select, car avec un "select *" DB2 pourra partir sur un scanage de table direct s'il évalue que tu vas ramener plus de 15-20% des enregistrement totale de ta table.

C'est aussi ce que je me suis dis. Je vais donc tenter ça. Merci.
Sinon il y a peu de chance que ca me renvoie plus de 1% de la table.
Mais je ne vois pas trop pour quelle raison il se mettrait à faire un scannage complet.

[CinePhil]

Envoyé par Hypnocrate

OK mais au final, le plan de requête est le même non?
Il va devoir passer en revue tous les c3 qui sont dans la table/liste.

Sauf que la jointure est l'opération la plus optimisée dans un SGBD et ce sera beaucoup plus rapide de faire en une requête et une seule transaction entre l'application et le SGBD que de faire une requête, une liste en java et une autre requête pour comparer à la liste, laquelle est longue.

Ne pas essayer de faire faire à un langage de programmation ce qui est le boulot du SGBD !

Et bien sûr, pour que la requête soit exécutée rapidement, il faut que les tables soient correctement indexées.