SQL LIKE %TOTO%

[SuperWaza]

Bonjour,
j'ai un problème de peformance avec une requête SQL sous DB2 Zos V9.1.

Je dois faire une recherche dans une chaîne de caractère ... table de 3.000.000 de records

Code :

1
2
 
LIKE %TOTO%

Hors par cette méthode, je scan ma table même avec un index sur la colonne.

Quelle technique puis-je utiliser ?

[punkoff]

Bonjour,

Un "like %valeur%" va entrainer systématiquement un scannage de table.

Ceci tout simplement car db2 (vous pouvez généraliser aux autres sgbd) ne peux utiliser d'index dans ce cas précis.

Comment "contourner" ce problème ?
- ne pas faire de like '%valeur%'
- rajouter d'autre clause de sélectivités dans le "WHERE"

A noté que si vous utilisez un like 'valeur%' db2 sera en mesure d'utiliser un index.

[pdz74]

Juste un ajout : le scan est certain, mais avec un index sur la colonne concernée, DB2 a de fortes chances de scanner l'index et non la table, ce qui sera moins pire, un index étant, la plupart du temps, beaucoup plus petit que la table. Mais quoi qu'il en soit, tu es parti pour scanner 3 millions de lignes.

[punkoff]

Envoyé par pdz74

Juste un ajout : le scan est certain, mais avec un index sur la colonne concernée, DB2 a de fortes chances de scanner l'index et non la table, ce qui sera moins pire, un index étant, la plupart du temps, beaucoup plus petit que la table. Mais quoi qu'il en soit, tu es parti pour scanner 3 millions de lignes.

ah, intéressant ! sous système i, un simple like '%valeur%' (sans d'autre critère de sélection) entraine systématiquement une stat de 20% de ligne sélectionnée dans la table en question => scannage de table.

Sous Z/OS c'est donc différent ?

[bernard59139]

Bonjour

Sous Z/OS c'est donc différent ?

Dans la documentation, c'est écrit que LIKE %toto est non-indexable.

Je pense que le TableScan sera toujours choisi. Mais l'optimiseur db2 étant une boite noire, on a rarement (et heureusement) quelques surprises.

Une remarque complémentaire:
quelques fois, il vaut mieux un TableScan avec utilisation du prefetch, qu'un indexscan qui lui, n'utilise pas le prefetch (ou pas très bien).
Surtout si la table a vécu dpuis la dernière reorg.

[pdz74]

Bonjour,

Bernard59139 a raison. J'ai fait un essai, DB2 refuse de passer par un index pour un LIKE '%TOTO%'. J'avoue que je l'apprends et que je ne comprends pas cette restriction. Si le prédicat est restrictif, le gain en scannant l'index serait conséquent.

Question bête : nous avons des quelques rares programmes qui font des LIKE host variable. DB2, ne sachant pas à l'avance ce que contiendra la host variable, décide de passer par l'index lors du bind statique. Je sais qu'il arrive que la host variable soit renseignée avec '%tOTO%'. Dans ce cas, DB2 change t'il de chemins d'accès en direct, ou est il capable de faire en statique ce qu'il n'arrive pas à faire en SQL dynamique.

Si quelqu'un a la réponse...

[punkoff]

De mon expérience, pour une même requête on peut avoir beaucoup de plan différent.
Sous systeme i, nous avons un plan cache qui stock les plans d'exécutions des requêtes. Pour une même requête il garde jusqu'à 3 plans d'accès différent.

Le plan va changer selon une multitude de critère, en particulier la sélectivité des prédicats de la close where (sachant que la sélectivité peut changer pour certaine valeur de variable), l'activité système, de la volumétrie des tables à l'instant où il fait la requête, etc ...

Dans votre cas, un like '%val', si db2 n'est pas en mesure d'utiliser un index pour faire ce test, le plan sera donc différent.

Mais vu que nous ne tournons pas sous le même OS, d'après ce que j'ai compris, les choses peuvent changer


Après je l'ai déjà vu faire ce genre de chose :
index prob suivi de test de table. Le test de table était là pour réaliser le like, l'index probe pour satisfaire d'autre restriction au niveau du where.

[pdz74]

Sous ZOS, les binds sont statiques, sauf si on se sert de l'option REOPT dans le BIND. Ce n'est pas notre cas, DB2 n'est donc pas sensé recalculer ses chemins d'accès lors de chaque exécution, mais prendre pour argent comptant ce qui a été définitivement décidé lors du bind. Dès que j'ai le temps, j'essayerai de retrouver l'un des programmes qui fait ça, lancer la transac correspondante en saisissant à l'écran les paramètres qui font qu'on va faire un LIKE '%TOTO%' et mettre une trace sur l'exécution. Je verrai alors si DB2 s'est ou non servi de l'index.