vendredi 30 octobre 2015

Clustering Factor

Clustering Factor ou en français Le facteur de foisonnement :

Clustering Factor établit le nombre de liens qu’il y a entre l’ensemble des feuilles de l’index et les blocs dans le tas. Il permet d’estimer si le fait que plusieurs valeurs se trouvent dans une même feuille d’index nécessitera plutôt peu de lecture de blocs différents dans le tas ou plutôt beaucoup.
Les données relatives au Clustering Factor sont disponibles dans la dictionnaire et on y accède par la requête suivante :

select t.INDEX_NAME,
       t.LEAF_BLOCKS,
       t.DISTINCT_KEYS,
       t.CLUSTERING_FACTOR
from sys.user_ind_statistics t 
where index_name like '%CLIENT%';


INDEX_NAME  LEAF_BLOCKS   DISTINCT_KEYS    CLUSTERING_FACTOR
-------------------- --------- -----------  -------------- ---------- -------------------------------
PK_CLIENTS                 94                 45000                            759
IS_CLIENTS_VILLE     130               1096                               43479


Clustering_Factor/Leaf_Blocks donne le nombre de liens qu’il y a en moyenne
entre une feuille et des blocs de données dans le tas : un ratio inférieur ou égal à 3
est excellent. Par contre, lorsque Clustering_Factor tend vers le nombre d’enregistrements, alors le Clustering Factor est considéré comme mauvais. Prenons deux cas pour illustrer le Clustering Factor :

Premier cas : L’index de clé primaire sur la colonne Nocmd de la table des commandes cmd. Si on suppose que les numéros de commandes sont créés séquentiellement, de façon ordonnée et jamais supprimés, le tas sera globalement dans le même ordre que l’index. Si l’index retourne plusieurs RowID depuis un même bloc (ce qui est caractéristique d’un prédicat sur une partie de clé ou sur un intervalle), alors il est probable que ces RowID désignent le même bloc ou peu de blocs différents dans le tas (puisque, généralement, il y aura plus de blocs dans le tas que de blocs d’index). Dans ce cas, le Clustering Factor sera bon.

Second cas:  Un index sur la colonne Ville dans la table des clients. Si on suppose que les clients n’agissent pas de façon concertée ou dirigée, alors ils seront mis dans le tas dans l’ordre suivant lequel ils ont passé leur première commande mais ils seront normalement dans des villes différentes. Donc, le fait de rechercher tous les clients situés à "Toulouse" retournera, depuis une ou plusieurs pages consécutives de l’index, des RowID qui désigneront des blocs qui seront probablement
sans aucun point commun. Dans ce cas, le facteur de foisonnement sera mauvais.

Un bon Clustering Factor permettra d’avoir de meilleures performances lors d’une opération Index Range Scan puisque, pour chaque feuille d’index, il y aura peu de blocs de données à charger depuis le tas. Pour les autres types d’accès, l’impact sera généralement faible. Un mauvais Clustering Factor aura pour effet de considérer un Index Range Scan moins intéressant.

Aucun commentaire:

Enregistrer un commentaire