Optimisation des jointures

Lorsque vous définissez une jointure, vous pouvez éventuellement définir la cardinalité pour décrire la relation entre les deux sources de données, c'est-à-dire 1..1, 1..n, n..1 et n..m.

Nous vous recommandons de toujours définir des cardinalités de jointure afin que l'optimiseur puisse décider si les jointures peuvent être omises au moment de l'exécution en fonction de la requête envoyée à la vue de calcul.

Si les tables sont utilisées comme sources de données et non comme vues de calcul, vous pouvez utiliser l'option Proposer cardinalité.

Avec une définition de jointure incluant des cardinalités, et sous des conditions supplémentaires, l'instanciation de la vue de calcul peut élaguer automatiquement une source de données impliquée dans un nœud de jointure. Examinons les conditions suivantes :

Le principe clé appliqué par l'optimiseur SQL est qu'il va élaguer une source jointe, en fonction du type de jointure et des cardinalités, uniquement si cela ne peut pas affecter l'ensemble de résultats. En d'autres termes, chaque fois que l'ensemble de résultats peut être différent selon que la jointure est exécutée ou non, la jointure est exécutée.

Voyons comment les cardinalités et le type de jointure permettent réellement à l'optimiseur de tailler.

Dans les trois exemples, basés sur le même scénario de point de départ, aucune colonne de la table de droite n'est demandée.

• Dans le cas d'une jointure externe gauche, la table droite R peut être ignorée car la cardinalité 1..1 indique à l'optimiseur que l'exécution de la jointure n'aura pas d'impact sur l'ensemble de résultats. En effet, pour chaque rangée en L, il y aurait au plus un match en R.

• Dans le deuxième exemple, en utilisant une jointure gauche mais une cardinalité 1..n, c'est l'inverse. Aucun élagage ne peut avoir lieu car la jointure peut correspondre à plus d'une ligne de R avec chaque ligne de L.

• Enfin, dans le cas d'une jointure externe droite, il n'est pas possible de élaguer la table de droite, quelle que soit la cardinalité. En effet, il n'est pas possible de savoir quelles lignes de L doivent être conservées dans l'ensemble de résultats sans exécuter la jointure.

Parmi les types de jointure, l'un est appelé Référentiel. Lorsque vous utilisez une jointure référentielle, vous indiquez à l'optimiseur que toute ligne d'une source a toujours une correspondance dans l'autre source. Par exemple, le poste de vente aura toujours un en-tête. Vous indiquez également si cette propriété est vraie pour la source gauche, la source droite ou les deux ; cette opération s'effectue avec la colonne Contrainte d'intégrité.

La jointure référentielle peut être considérée comme une jointure interne prenant en charge l'optimisation. Avec la cardinalité réelle définie, elle renvoie toujours le même ensemble de résultats qu'une jointure interne et utilise la contrainte d'intégrité (en plus des autres paramètres généraux de conditions d'élagage mentionnés précédemment) pour décider si l'exécution de la jointure peut être ignorée (et une table élaguée) pour augmenter les performances.

Les jointures sont une source potentielle d'amélioration des performances. Assurez-vous de prendre en compte toutes les recommandations lors de la définition des jointures pour vous assurer d'obtenir les meilleures performances à partir de vos vues calculées.

Nous avons déjà abordé l'élagage des sources de données dans une jointure, mais vous devriez en apprendre davantage sur une autre possibilité d'optimisation. Dans la source de données restante, la colonne qui faisait partie de la jointure peut-elle également être élaguée ?

SAP HANA Cloud QRC 3/2022 a introduit un nouveau type d'optimisation des jointures appelé Greedy Join Pruning. Il permet à l'optimiseur SQL d'élaguer une source jointe si elle n'est pas du tout interrogée (aucune colonne demandée), quels que soient les paramètres de cardinalités et de type de jointure. Cela peut considérablement améliorer la durée d'exécution de la requête. Cependant, vous devez l'utiliser uniquement lorsque les résultats attendus ne dépendent pas de l'exécution ou non de la jointure.

Pour ce faire, vous définissez l'option Pruning gourmand d'une jointure sur Gauche, Droite ou Les deux. Gauche ou Droite font référence à la source jointe qui peut être élaguée en mode gourmand.

Greedy Pruning peut être défini à trois niveaux différents :

La colonne de priorité de la table précédente signifie que, par exemple, un paramètre d'élagage gourmand défini pour une vue calculée entière remplace tout paramètre d'élagage gourmand défini dans l'une de ses jointures. De même, un indice d'élagage gourmand dans une requête SQL remplace tout paramètre défini pour l'ensemble de la vue de calcul ou dans une jointure spécifique.