[ase 12.5][tsql] Sarg [Résolu]

[Jean.Cri1]

Qui peut parler du SARG appliqué aux optimisation de requettes sous Sybase en particulier, ou peut indiquer un lien qui en parle clairement ?

D'avance merci.

[mpeppler]

Un premier lien - un document ecrit par Eric Miner (ingénieur Sybase en charge de l'optimiseur pendant de nombreuses années) en 1997:

http://www.sybase.com/detail?id=2602

Je pense que ce document explique aussi d'où viennent les "magic numbers"...

Le manuel P&T actuel a pas mal d'explication sur les SARGs, et comment l'optimiseur se comporte. Par example:

http://manuals.sybase.com/onlinebook...58945;pt=58855

Voila pour un début...

Michael

[fadace]

je suis Michael sur le P&T de Sybase : c'est sans doute le bouquin le plus complet sur la matière.

Pour les SARGs, bien que le nom diffère, l'utilisation des diverses conditions et jointures par l'optimiseur répondent à certaines règles similaires, quelle que soit la base. On peut déplorer chez Sybase par exemple le fait que les indexes sur fonction n'existent pas, mais on peut se réjouir par contre que l'optimiseur, dans son calcul de poids pour le choix optimum du bon SARG, est en mesure de différencier les pages en caches des pages en disque et de leur attribuer un poid différent, contrairement à l'optimiseur d'Oracle par exemple.

Pour essayer de faire simple:

• afin de rechercher l'accès le plus rapide aux pages utiles à répondre à la requête, l'optimiseur relève toutes les assertions utiles dans les jointures (clause FROM avec jointures ANSI), dans les conditions (Clauses WHERE) et dans certains autres cas (aggrégat), dans le HAVING, le GROUP BY et des fonctions d'aggrégat.

• il traite ensuite chacune des assertions en détectant si elle est sujette à utiliser un (ou des indexes). Si elle remplit les conditions d'une SARG, c'est qu'elle l'est. par exemple, une condition du type "WHERE Col1+3 = Col2-1" ne'st pas une SARG puisque Col1+3 ne peut pas se référer à un index. Par contre, la même assertion logique "Col1 = Col2+2" en est une puisque l'optimiseur pourra dans cas utiliser un éventuel index sur Col1.
• Ayant fait ce premier tri, l'optimiseur va calculer chaque chemin d'accès (= quel poind donner à chaque SARG pour chaque index) afin de choisir le chemin optimal.
• Dans des cas de bord, il peut s'avérer plus rapide de traverser une table par full scan que d'utiliser un index, si par exemple toutes les pages de la table sont en cache, et que l'index lui est en disque...

Le magic number est un poids arbitraire (et souvent mauvais) que l'optimiseur donne pour une condition donnée lorsqu'une valeur meilleure n'est pas disponible via la table des statistiques ou qu'il n'est pas en mesure de déterminer la colonne au moment de la compilation (d'où éviter les derivative tables, les sql dynamiques, ...) pour la sélectivité d'un index. Il n'y a pas que 30%... il y a plusieurs poids selon le type de condition. En teme de statistique toujours, Sybase est à mon avis bien meilleur qu'Oracle, car ses statistiques sont généralement mises à jour au fil de l'eau.