Opérations

Ma ressource favorite sur les opérations des plan d'exécution est la liste de Julian. Néanmoins, cela vient d'un point de vue différent.

Accès aux tables et aux index

INDEX UNIQUE SCAN

L'opération INDEX UNIQUE SCAN réalise un parcours seul du B-tree. La base de données utilise cette opération si une contrainte unique assure que le critère de recherche correspondra à pas plus d'une entrée. Voir aussi le Chapitre 1, « Anatomie d'un index SQL ».

INDEX RANGE SCAN

L'opération INDEX RANGE SCAN réalise un parcours du B-tree et suit la chaîne de nœuds feuilles pour trouver toutes les entrées correspon­dantes. Voir aussi le Chapitre 1, « Anatomie d'un index SQL ».

Les prédicats de filtre de l'index causent souvent des problèmes de performance pour un INDEX RANGE SCAN. La section suivante explique comment les identifier.

INDEX FULL SCAN

Lit l'index entier (toutes les lignes) dans l'ordre de l'index. Suivant différentes statistiques système, la base de données peut choisir de réaliser cette opération car elle a besoin de toutes les lignes dans l'ordre de l'index, par exemple à cause d'une clause order by. À la place, l'optimiseur pourrait aussi utiliser un INDEX FAST FULL SCAN et réaliser une opération de tri supplémentaire. Voir le Chapitre 6, « Trier et grouper ».

INDEX FAST FULL SCAN

Lit l'index en entier (toutes les lignes) comme stocké sur disque. Cette opération est typiquement exécutée à la place d'un parcours complet de table si toutes les colonnes requises sont disponibles dans l'index. Comme le TABLE ACCESS FULL, l'opération INDEX FAST FULL SCAN peut bénéficier d'opérations de lecture multi-blocs. Voir le Chapitre 5, « Regrouper les données : La deuxième puissance de l'indexation ».

TABLE ACCESS BY INDEX ROWID

Récupère une ligne à partir de la table en utilisant le ROWID récupéré lors d'une recherche précédente dans l'index. Voir aussi le Chapitre 1, « Anatomie d'un index SQL ».

TABLE ACCESS FULL

Cette opération est aussi connue sous le nom de parcours complet de table. Elle lit la table entière, toutes les lignes et toutes les colonnes, comme elle est stockée sur le disque. Bien que les opérations multi-blocs accélèrent fortement la rapidité d'un parcours complet de table, c'est l'une des opérations les plus coûteuses. En dehors de gros taux d'entrées/sorties, un parcours complet de table doit inspecter toutes les lignes de la table, donc il peut aussi consommer beaucoup de temps processeur. Voir aussi le « Parcours complet de table ».

Jointures

Généralement, les opérations de jointure traitent deux tables à la fois. Au cas où la requête a plus de jointures, elles sont exécutées séquentiellement : tout d'abord deux tables, puis le résultat intermédiaire et la table suivante. Dans le contexte des jointures, le terme « table » peut aussi signifier « résultat intermédiaire ».

NESTED LOOPS JOIN

Joint deux tables en récupérant le résultat d'une table et en recherchant la condition de jointure dans l'autre table ligne par ligne. Voir aussi « Boucles imbriquées ».

HASH JOIN

La jointure de hachage charge les enregistrements candidats d'un côté de la jointure dans une table de hachage qui est ensuite sondée pour chaque ligne de l'autre côté de la jointure. Voir aussi « Jointure par hachage ».

MERGE JOIN

La jointure d'assemblage combine deux listes triées comme une fermeture Éclair. Les deux côtés de la jointure doivent être pré-triés. Voir aussi « Fusion par tri ».

Tri et regroupement

SORT ORDER BY

Trie le résultat suivant la clause order by. Cette opération a besoin de grandes quantités de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). Voir aussi « Indexer un tri ».

SORT ORDER BY STOPKEY

Trie un sous-ensemble du résultat suivant la clause order by. Utilisé pour les requêtes top-N si une exécution en pipeline n'est pas possible. Voir aussi « Récupérer les N premières lignes ».

SORT GROUP BY

Trie l'ensemble de résultat sur les colonnes de la clause group by et agrège le résultat trié dans une deuxième étape. Cette opération a besoin de grandes quantités de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). Voir aussi « Indexer le Group By » à la page %p.

SORT GROUP BY NOSORT

Agrège un ensemble pré-trié suivant la clause group by. Cette opération ne place pas le résultat intermédiaire dans un tampon : il est exécuté dans un pipeline. Voir aussi « Indexer le Group By » à la page %p.

HASH GROUP BY

Groupe les résultats suivant une table de hachage. Cette opération a besoin de grandes quantités de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). La sortie n'est pas ordonnée de quelle que façon que ce soit. Voir aussi « Indexer le Group By » à la page %p.

Requêtes Top-N

L'efficacité des requêtes top-N dépend du mode d'exécution des opérations sous-jacentes. Elles sont très inefficaces lors de l'arrêt d'opérations sans pipeline, comme SORT ORDER BY.

COUNT STOPKEY

Arrête les opérations sous-jacentes quand le nombre de lignes souhaité a été atteint. Voir aussi « Récupérer les N premières lignes ».

WINDOW NOSORT STOPKEY

Utilise une fonction de fenêtrage (clause over) pour arrêter l'exécution quand le nombre de lignes a été récupéré. Voir aussi « Utiliser les fonctions de fenêtrage pour une pagination efficace ».