Discussion :

[SuperWaza]

Y a-t-il une influence au niveau performances des requêtes si la liste des tables - colonnes ne sont pas toujours dans le même ordre ?

J'ai vu cette remarque sur ce site et voudrais avoir plus d'explications à ce sujet ...

Remaniez vos requête de façon à lire les tables toujours dans le même ordre (par exemple l'ordre alphabétique des nom des tables) de façon à prévenir les verrous mortels et les temps d'attente trop long dus à des interblocages.

[bernard59139]

Dans sa documentation "application programming and sql guide", ibm dit que l'ordre des tables dans la clause FROM peut influencer le chemin d'accès aux données (eq les performances).

Rearranging the order of tables in a FROM clause
The order of tables or views in the FROM CLAUSE can affect the access path. If your query performs poorly, it could be because the join sequence is inefficient. You can determine the join sequence within a query block from the PLANNO column in the PLAN_TABLE. For information on using the PLAN_TABLE, see Chapter 27, “Using EXPLAIN to improve SQL performance,” on page 789.
If you think that the join sequence is inefficient, try rearranging the order of the tables and views in the FROM clause to match a join sequence that might perform better.

.
Mais IBM ne dit pas pourquoi. Et personnellement, je n'ai jamais pu optimiser une requête juste en changeant l'ordre des tables.

Je pense que ca doit être lié à aux méthodes de calcul utilisées par l'optimiseur DB2, méthodes basées sur une accumulation de calculs de ratios et de décisions successives liées à ces ratios.

[Luc Orient]

...
Remaniez vos requête de façon à lire les tables toujours dans le même ordre (par exemple l'ordre alphabétique des nom des tables) de façon à prévenir les verrous mortels et les temps d'attente trop long dus à des interblocages.

Je pense que ce conseil, judicieux au demeurant, ne concerne pas l'écriture d'une seule requête (une jointure par exemple) mais plutôt l'enchaînement de plusieurs requêtes successives dans des programmes différents.

[Mercure]

J'espère que les éclaircissements qui concernent ici DB2/400 (BDD de l'AS/400, iSeries, System i) et que je publie ci-dessous apporteront un peu d'eau au moulin des performances SQL car il est en effet hautement probable qu'il existe une forte similitude entre les diverses DB2 UDB.

Comment fonctionne SQL

La première fois qu'une instruction SQL est exécutée, la totalité de la procédure d'optimisation est mise en oeuvre, c'est à dire :

• la récriture de l'instruction SQL,
• le contrôle de tous les index existants
• la création des objets temporaires nécessaires pour accomplir la requête (tables de hâchage, listes de RRN, bitmaps, etc),
• la création d'un plan d'accés, qui définit la méthode avec laquelle accéder aux données, quels index utiliser et quels objets temporaires doivent être éventuellement construits,
• la création de l'ODP (Open Data Path).
  

A la fin de la première exécution de l'instruction SQL, le curseur fait l'objet d'un hard-close et l'ODP est supprimé. Au deuxième passage de la même instruction, le plan d'accés est validé et l'ODP est rouvert. A partir du troisième passage de la même instruction, l'ODP reste ouvert et seules les données sont réactualisées dans l'ODP. Vous pouvez donc constater que l'exécution de la totalité de la procédure d'optimisation prend beaucoup de temps. Souvenez-vous que cette procédure est effectuée pour chaque instruction SQL.

On peut alors raisonnablement penser qu'il est préférable d'éviter de changer l'ordre dans lequel les tables et les colonnes sont placées sur une requête SQL déjà établie pour ne pas avoir à exécuter de nouveau la totalité de la procédure d'optimisation.
En outre, la plupart du temps, les requêtes "rament" par manque d'index adéquats. Voyez votre Explain qui vous montre les index que l'optimiseur a dû créer et la méthode d'accés aux données de la requête. C'est toujours édifiant et formateur.

[pdz74]

Bonjour,

En ce qui me concerne, je suis toujours parti du principe que l'ordre des tables dans une jointure n'a strictement aucune importance, sous réserve que les clauses ON soient correctement codifiées. Et avec une jointure écrite à la méthode ibm (toutes les tables dans la clause from et les prédicats de jointure dans la clause where), il n'y a aucun souci. Pourquoi prendre l'ordre alphabétique, c'est totalement aléatoire. L'optimiseur calcule tous les chemins d'accès possibles et choisira ses chemins d'accès indépendament de l'ordre des tables. Perso, je ne suis jamais tombé sur un cas où l'ordre des tables changeait quelque chose. Et si c'était le cas, j'ouvrirais aussitôt un incident auprès d'IBM, car cela parait totalement illogique.

Bien sur, tout ceci est valable pour les jointure standards. Pour les jointures externes, l'ordre des tables devient totalement significatif, que ce soit pour les lignes renvoyées comme pour les temps de réponse. Mais je ne pense pas qu'il s'agisse du sujet du jour.

Quant au temps de calcul des chemins d'accès, il peut être significatif pour les grosses jointures (plus de 10 ou 12 tables), mais si la requête est dans un programme, seul le bind sera affecté. Ensuite, lors de l'exécution, plus de souci.

A votre disposition et bonne journée.

[Mercure]

ça serait quand même bien que SuperWaza, l'OP initial, veuille bien nous donner signe de vie, n'est-ce pas ?

[SuperWaza]

Merci pour vos remarques