ASA - Guide de l'utilisateur SQL
Contrôle et amélioration des performances
Les tables de travail sont des jeux de résultats matérialisés, qui sont créées lors de l'exécution d'une requête. Lorsqu'Adaptive Server Anywhere détermine que le coût de l'une de ces tables est inférieur aux stratégies décrites précédemment, il les utilise. Avec une table de travail, la lecture des premières lignes prend généralement plus de temps mais, dans certaines circonstances, ce type de table contribue à réduire considérablement le coût d'extraction de toutes les lignes. C'est pourquoi, Adaptive Server Anywhere choisit des stratégies différentes en fonction de la valeur de l'option OPTIMIZATION_GOAL. La valeur par défaut est first-row. Lorsque cette valeur est définie, Adaptive Server Anywhere évite d'utiliser des tables de travail. Lorsque la valeur Toutes les lignes est définie, Adaptive Server Anywhere utilise des tables de travail si elles réduisent le coût d'exécution total d'une requête.
Les tables de travail s'utilisent dans les cas suivants :
Lorsqu'une requête comporte une clause ORDER BY, GROUP BY ou DISTINCT, Adaptive Server Anywhere n'utilise pas d'index pour trier les lignes. S'il existe un index approprié et si l'option OPTIMIZATION_GOAL a la valeur Première ligne, Adaptive Server Anywhere évite d'utiliser une table de travail. Si l'option OPTIMIZATION_GOAL a la valeur Toutes les lignes, il peut être plus coûteux de lire toutes les lignes d'une requête à l'aide d'un index que de créer une table de travail et de trier les lignes. Adaptive Server Anywhere choisit la stratégie la moins coûteuse si l'option OPTIMIZATION GOAL a la valeur Toutes les lignes. Pour les instructions GROUP BY et DISTINCT, les algorithmes de hachage utilisent des tables de travail, mais ils sont généralement plus efficaces pour extraire toutes les lignes d'une requête.
Lorsqu'un algorithme Hash join est choisi, des tables de travail sont utilisées pour stocker les résultats temporaires (si la mémoire ne peut contenir toutes les entrées) et les résultats de la jointure.
Lorsqu'un curseur est ouvert avec des valeurs sensibles, une table de travail est créée pour stocker les identificateurs de ligne et les clés primaires des tables sous-jacentes. Cette table de travail est remplie à mesure que les lignes sont lues de haut en bas à partir de la requête. Cependant, si vous lisez la dernière ligne à partir du curseur, toute la table est remplie.
Lorsqu'un curseur est ouvert avec des données non sensibles, une table de travail est remplie avec les résultats de la requête lors de l'ouverture de celle-ci.
Lorsqu'une commande UPDATE portant sur plusieurs lignes est exécutée et que la colonne mise à jour est incluse dans la clause WHERE de la mise à jour ou dans un index associé.
Lorsqu'une commande UPDATE ou DELETE portant sur plusieurs lignes inclut dans la clause WHERE une sous-requête référençant la table en cours de modification.
Lorsqu'une commande INSERT d'une instruction SELECT est exécutée et que l'instruction SELECT fait référence à la table d'insertion.
Lorsqu'une commande INSERT, UPDATE ou DELETE est exécutée et qu'un trigger correspondant susceptible de déclencher l'opération est défini dans la table.
Dans tous ces cas, les enregistrements affectés par l'opération sont insérés dans la table de travail. Dans certaines situations, par exemple avec des curseurs orientés clavier, un index temporaire est créé sur la table de travail. L'opération d'extraction des enregistrements concernés dans une table de travail peut prendre beaucoup de temps avant l'apparition des résultats de la requête. La création d'index qui peuvent être utilisés pour effectuer le tri dans le premier cas réduit le temps d'extraction des premières lignes. Toutefois, la durée totale de la lecture de toutes les lignes peut être réduite si des tables de travail sont utilisées, car elles autorisent des algorithmes de requête fondés sur le hachage et le tri par fusion. Ces algorithmes emploient des E/S séquentielles plus rapides que les E/S aléatoires utilisées dans le balayage d'index.
L'optimiseur de requête du serveur de base de données analyse chaque requête pour déterminer si une table de travail procurera les meilleures performances. Les enrichissements apportés à l'optimiseur dans les nouvelles versions d'Adaptive Server Anywhere peuvent améliorer les plans d'accès aux données pour les requêtes. Aucune intervention de l'utilisateur n'est requise.
Les autres cas (INSERT, UPDATE et DELETE) de l'exemple ci-dessus ne posent généralement pas de problème de performances, les opérations correspondantes étant exécutées en une seule fois. Toutefois, en cas de problème, vous pouvez reformuler la commande pour éviter tout conflit et la création d'une table de travail. Mais cela n'est pas toujours possible.
SQL Anywhere Studio 9.0.1
Copyright © 1989–2004 Sybase, Inc. Copyright partiel © 2001–2004 iAnywhere Solutions, Inc. Tous droits réservés.