Discussion :

[Boubou2020]

bonjour
Nous rencontrons comme chaque année quelques lenteurs liées à notre forte activité estivale ,j'ai lancer trace de profiler je viens de détecter que cette requéte prend beaucoup du temps

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select count (distinct id_etiquette) from mvttests where id_transaction in (1,2) and date_creation between '12/10/2015 06:00:00' and '13/10/2015 05:59:59' and Mvttests.site ='MG' and Mvttests.statutok='True'

donc afin d'optimiser j'ai penser a ajouter un index couvrant sur ma table surtout je poséde un seul index cluster qui pointe que sur le colonne id_etiquette
alors j'était devant deux choix de script de création

soit le script 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 
CREATE NONCLUSTERED INDEX [_dta_index_Mvttests_25_638625318__K11_K6_K10_K3_K2] ON [dbo].[Mvttests]
(
	[Site] ASC,
	[date_Creation] ASC,
	[StatutOK] ASC,
	[Id_Transaction] ASC,
	[id_Etiquette] ASC
)WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

soit utilisé le scrip2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE NONCLUSTERED INDEX [_dta_index_Mvttests_25_638625318__K11_K6_K10_K3_K2] ON [dbo].[Mvttests]
(
	[id_Etiquette] ASC
)INCLUDE ([Site] ASC,
	[date_Creation] ASC,
	[StatutOK] ASC,
	[Id_Transaction] ASC)
WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

Qui est le meuleur choix et merci pour votre réponsse

[aieeeuuuuu]

Bonjour

Le premier semble mieux, notamment car il permet de filtrer sur la date.
Il faudra peut être revoir l'ordre des colonnes, pour mettre les plus discriminantes en premier.
difficile d'être plus précis sans connaitre le contexte, la volumétrie, les cardinalités,...


si id_etiquette est la clef primaire cluster de votre table, alors inutile de l'ajouter dans les index. inutile également de faire un DISTINCT dans le COUNT, puisqu'il n'y aura pas de doublons, et inutile même de préciser la colonne, puisqu'il n'y aura pas de NULL

[bvesan]

Bonjour,
Le second indexe n'a que peu de chances d'être utilisé si vous avez effectivement un indexe clusterisé sur la colonne id_etiquette, parce qu'il est très similaire à la définition de cet indexe clusterisé (tout dépend des autres colonnes de la table et de la taille totale de l'indexe par rapport à celui de la table).

Le meilleur indexe pour votre requête sera celui qui permettra d'identifier les lignes à remonter avec le moins de pages lues. Il est donc important d'y placer en premier les colonnes les plus sélectives. Donc comme l'a indiqué aieeeuuuuu, il serait intéressant de connaître les différentes cardinalités de vos valeurs filtrées, ainsi que le volume total de la table (lignes et taille ).

N'oubliez pas l'existence des indexes filtrés (si votre instance est en version 2008 ou supérieure) qui peut sans doute vous aider sur cette requête précisément, par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE NONCLUSTERED INDEX IDX_FILTRE ON mvttests(date_creation) WHERE id_transaction IN(1,2) AND site='MG' and statutok='True';

Attention, l'utilisation des indexes filtrés est soumise à contrainte (ANSI_NULLS à ON), ce qui peut poser problème...