Discussion :

[bonbledfb]

Bonjour,

j'ai une table avec X record par date extraction, avec un index sur la zone de date d'extraction.

Code :

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

1
2
3
SELECT [fk_extract_date], count( pk_broadcast )
  FROM [RMBDW_DEV].[dbo].[f_broadcast]
group by [fk_extract_date]

fk_extract_date    (No column name)
20140131    233480
20140801    1091005
20141231    1809616
20150109    183188
20150116    211225
20150130    185851
20150206    216804
20150213    238989
20150220    268964
20150227    289685
20150306    321151
20150313    346335
20150320    359229
20150327    384923
20150403    413655
20150410    438869
20150417    467610
20150424    494460
20150501    520254
20150508    645015
20150515    665559
20150522    702123
20150529    730841
20150605    764339
20150612    787066
20150619    823706
20150626    858059
20150703    890583
20150710    917796
20150713    925899
20150714    929909
20150715    934274
20150716    941102
20150717    945510
20150720    945535
20150721    945763
20150722    949220
20150723    956129
20150724    960656
20150727    967244

lorsque je lance un select avec certaine valeur sur fk_extract_date :

Code :

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

select id_break from rmbdw_dev.dbo.f_broadcast where fk_extract_date = 20150206

--> il utilise bien l'index , et la réponse est immédiate.

et le même select sur d'autre valeur de fk_extract_date, l'index n'est pas utilisé , et l'explain plan donne un scan complet la table.

Code :

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

select id_break from rmbdw_dev.dbo.f_broadcast where fk_extract_date = 20150720

si je force l'utilisation de l'index, cela fonctionne de nouveau très bien.

Code :

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

select id_break from rmbdw_dev.dbo.f_broadcast with( INDEX (IDX_f_broadcast_extract)) where fk_extract_date = 20150720

Quelqu'un aurai-il une idée sur la raison de la non utilisation automatique de l'index pour chaque valeur de fk_extract_date ?


Merci.

Franck.

[aieeeuuuuu]

Bonjour,

1/ est-ce que les statistiques sont a jour ?

2/ peut-on voir le CREATE de l'index

[bonbledfb]

Bonjour,

1/ est-ce que les statistiques sont a jour ?

2/ peut-on voir le CREATE de l'index

1/ le problème continue après recalcul des statistiques sur cette table.


2/

Code :

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

1
2
3
4
5
CREATE NONCLUSTERED INDEX [IDX_f_broadcast_extract] ON [dbo].[f_broadcast]
(
	[fk_extract_date] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

merci pour vos conseils.

[SQLpro]

Créez l'index suivant :

Code :

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

CREATE INDEX ??? ON [RMBDW_DEV].[dbo].[f_broadcast] ([fk_extract_date]) INCLUDE (pk_broadcast);

A +

[bonbledfb]

Créez l'index suivant :

Code :

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

CREATE INDEX ??? ON [RMBDW_DEV].[dbo].[f_broadcast] ([fk_extract_date]) INCLUDE (pk_broadcast);

A +

Même résultat après création de l'index avec l'INCLUDE pk_broadcast

[aieeeuuuuu]

C'est plutôt la colonne id_break qu'il faudrait inclure, car c'est sur elle que porte le SELECT.

l'index deviendra couvrant, et devrait donc être utilisé systématiquement.

[mikedavem]

Attendons effectivement les informations demandés par aieeeuuuuu mais de loin il semble que la distribution de tes données dans ton cas fait que SQL Server choisisse ou non une recherche d'index.

En regardant rapidement le nombre d'enregistrements par date, on voit déjà que pour la date 20150720 SQL Server devra ramener 945535 lignes alors que pour la date 20150206 seulement 216804 ce qui représente 77% de données en moins. A voir également si tes statistiques reflètent la réalité. L'optimiseur peut se tromper si les statistiques ne sont pas à jour.

Tu peux nous fournir le plan d'exécution réel dans les 2 cas stp . Tu n'aurais pas un key / RID lookup dans tes plans d'exécution par hasard?

++

[bonbledfb]

Attendons effectivement les informations demandés par aieeeuuuuu mais de loin il semble que la distribution de tes données dans ton cas fait que SQL Server choisisse ou non une recherche d'index.

En regardant rapidement le nombre d'enregistrements par date, on voit déjà que pour la date 20150720 SQL Server devra ramener 945535 lignes alors que pour la date 20150206 seulement 216804 ce qui représente 77% de données en moins. A voir également si tes statistiques reflètent la réalité. L'optimiseur peut se tromper si les statistiques ne sont pas à jour.

Tu peux nous fournir le plan d'exécution réel dans les 2 cas stp . Tu n'aurais pas un key / RID lookup dans tes plans d'exécution par hasard?

++

Explain plan avec la sélection automatique de l'index.




Explain plan sans la sélection de l'index