-
COÛT du création index
Bonjour
j'ai une requête du reporting qui est très coûteuse en terme consommation CPU
il est utilisé sur mon serveur du production ci joint leur syntaxe
Code:
SELECT DISTINCT pr_num FROM dbo.mvtFabr WHERE (mf_trans = 'assemb') GROUP BY pr_num
en analysant cette dernier avec l'assistant du moteur SGBD il ma demandé de crée un index non_cluster qui pointe sur les deux colonnes "pr_num" et "mf_trans" ce qui m’inquiète c'est le coût de leur création en terme espace il va occupé plus de 15G vu que mon table est volumineux
sur la même piste j'ai un autre index existant qui pointe que sur le colonne "pr-num" seulement
ma question si j'utilise l'option include sur cette index en ajoutant le colonne "mf_trans" est ce que je peut couvrir ma requête et en parallèle je gagne d'espace surtout que mon index est déjà cré et je ne serai pas obliger de perdu 15G
merci pour vos aide
-
Bonjour,
Déjà, pourquoi avez-vous ce GROUP BY ?
Je n'en vois pas l'utilité, car vous n'utilisez pas de fonction d'agrégat, et il est de fait redondant avec le DISTINCTSi votre filtre est toujours sur la même valeur, vous pouvez ajouter une index filtré : WHERE mf_trans = 'assemb'Vous pourriez aussi envisager une vue indéxée (la table est elle souvent mise à jour ?)
Ajouter votre colonne mf_trans à l'index existant eviterait en effet un accés à la table, mais ne serait pas pour autant l'idéal. Il vous faudrait dans votre cas un index sur (mf_trans,pr_num).
Dites-en un peu plus sur le contexte, on pourra mieux vous orienter.
-
Le meilleur index serait :
Code:
CREATE INDEX X... ON dbo.mvtFabr (mf_trans) INCLUDE (pr_num);
sauf si pr_num est un clef primaire CLUSTERED ou fait partie d'un index CLUSTERED, auquel cas la clause INCLUDE n'est pas nécessaire
Le group BY n'est effectivement pas nécessaire.
Enfin, la volumétrie d'un index n'a aucun intérêt en soit. Ne vous en préoccupez pas. L'index ne sera utilisé que pour les quelques pages nécessaire !
A +
