par Guillaume Lelarge.

Opérations


Cette section explique les opérations les plus communes sur un plan d'exécution de la base de données SQL Server de Microsoft. Vous pouvez aussi jeter un œil à la documentation de Microsoft.

Accès aux tables et aux index

SQL Server a une terminologie simple : les opérations « Scan » lisent la totalité de l'index ou de la table, alors que les opérations « Seek » utilisent le B-tree ou une adresse physique (RID, équivalent de ROWID sur Oracle) pour accéder à une partie spécifique de l'index ou de la table.

Index Seek, Clustered Index Seek

L'opération Index Seek effectue un parcours B-tree et suit la chaîne de nœuds feuilles pour trouver toutes les entrées correspondantes. Voir aussi « Anatomie d'un index SQL ».

Index Scan, Clustered Index Scan

Lit entièrement l'index (toutes les lignes) dans l'ordre de l'index. Selon diverses statistiques systèmes, la base de données peut utiliser cette opération si elle a besoin de toutes les lignes dans l'ordre de l'index, par exemple pour une clause order by correspondante.

Key Lookup (Clustered)

Récupère une ligne unique à partir d'un index organisé. Ceci est équivalent à un INDEX UNIQUE SCAN sur Oracle pour une table organisée en index (IOT). Voir aussi « Regrouper les données ».

RID Lookup (Heap)

Récupère une ligne unique à partir d'une table, équivalent au TABLE ACCESS BY INDEX ROWID sur Oracle. Voir aussi « Anatomie d'un index SQL ».

Table Scan

Cette opération est également connue comme un parcours complet de table. Elle lit entièrement la table, lignes et colonnes, comme stockées sur le disque. Bien que des opérations de lecture multi-blocs puissent améliorer considérablement la vitesse d'un Table Scan, il s'agit quand même d'une des opérations les plus coûteuses. En dehors des taux élevés d'entrées/sorties, un Table Scan doit également inspecter toutes les lignes de la table, et par conséquent requérir une quantité considérable de temps processeur. Voir aussi « Parcours complet de table ».

Jointures

En général, les opérations de jointure ne traitent que deux tables en même temps. Dans le cas où une requête a plus de tables jointes, elles sont exécutées séquentiellement : d'abord deux tables, puis le résultat intermédiaire avec la table suivante. Dans le contexte de jointure, le terme « table » peut aussi signifier « résultat intermédiaire ».

Nested Loops

Joint deux tables en récupérant le résultat d'une table et en requêtant l'autre table pour chacune des lignes de la première. SQL Server utilise également des opérations de boucles imbriquées pour récupérer des données de table après un accès d'index. Voir aussi « Boucles imbriquées ».

Hash Match

La jointure par correspondance de hachage charge les enregistrements candidats à partir d'un côté de la jointure dans une table de hachage, qui est alors sondée pour chacune des lignes 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

Trie le résultat selon la clause order by. Cette opération nécessite une grande quantité de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). Voir aussi « Indexer un tri ».

Sort (Top N Sort)

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

Stream Aggregate

Agrège un ensemble pré-trié selon 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 .

Hash Match (Aggregate)

Groupe les résultats en utilisant une table de hachage. Cette opération nécessite une grande quantité de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). La sortie n'est pas triée. Voir aussi .

Requêtes Top-N

Top

Annule les opérations sous-jacentes quand le nombre désiré de lignes a été récupéré. Voir aussi « Récupérer les N premières lignes ».

L'efficacité d'une requête top-N dépend du mode d'exécution des opérations sous-jacentes. C'est très inefficace lors de l'arrêt d'opérations ne fonctionnant pas en pipeline, comme un Sort par exemple.

À propos de l'auteur

Photo de Markus Winand

Markus Winand teaches efficient SQL—inhouse and online. He minimizes the development time using modern SQL and optimizes the runtime with smart indexing—for that he also published the book SQL Performance Explained.

Livre de Markus

Couverture du livre « SQL : Au cœur des performances »

L'essence de SQL tuning dans 200 pages.

Acheter de Markus
(Livre de poche et PDF)

Achetez chez Amazon
(Seulement en poche)

“Use The Index, Luke!” by Markus Winand and translated by Guillaume Lelarge is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Mentions légales | Contact | NO WARRANTY | Marque déposée | Privacy | CC-BY-NC-ND 3.0 license