Je teste différentes architectures pour de grandes tables et une suggestion que j'ai vue est d'utiliser une vue partitionnée, par laquelle une grande table est divisée en une série de tables plus petites et "partitionnées".
En testant cette approche, j'ai découvert quelque chose qui n'a pas beaucoup de sens pour moi. Lorsque je filtre sur "colonne de partitionnement" sur la vue des faits, l'optimiseur ne recherche que sur les tables pertinentes. De plus, si je filtre sur cette colonne de la table de dimension, l'optimiseur élimine les tables inutiles.
Cependant, si je filtre sur un autre aspect de la dimension que l'optimiseur recherche sur le PK / CI de chaque table de base.
Voici les requêtes en question:
select
od.[Year],
AvgValue = avg(ObservationValue)
from dbo.v_Observation o
join dbo.ObservationDates od
on o.ObservationDateKey = od.DateKey
where o.ObservationDateKey >= 20000101
and o.ObservationDateKey <= 20051231
group by od.[Year];
select
od.[Year],
AvgValue = avg(ObservationValue)
from dbo.v_Observation o
join dbo.ObservationDates od
on o.ObservationDateKey = od.DateKey
where od.DateKey >= 20000101
and od.DateKey <= 20051231
group by od.[Year];
select
od.[Year],
AvgValue = avg(ObservationValue)
from dbo.v_Observation o
join dbo.ObservationDates od
on o.ObservationDateKey = od.DateKey
where od.[Year] >= 2000 and od.[Year] < 2006
group by od.[Year];
Voici un lien vers la session SQL Sentry Plan Explorer.
Je travaille sur le partitionnement de la plus grande table pour voir si j'obtiens l'élimination de la partition pour répondre de la même manière.
J'obtiens l'élimination de partition pour la requête (simple) qui filtre sur un aspect de la dimension.
En attendant, voici une copie uniquement statistique de la base de données:
https://gist.github.com/swasheck/9a22bf8a580995d3b2aa
L'estimateur de cardinalité «ancien» obtient un plan moins cher, mais c'est à cause des estimations de cardinalité plus faibles pour chacun des indices (inutiles) recherchés.
Je voudrais savoir s'il existe un moyen pour que l'optimiseur utilise la colonne clé lors du filtrage par un autre aspect de la dimension afin qu'il puisse éliminer les recherches sur les tables non pertinentes.
Version de SQL Server:
Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
ObservationDates
tableau. Je ne reçois pas le même plan que Paul, même avec 4199, et je pense que c'est pourquoi.
ObservationDates
. J'ai fini par courir UPDATE STATISTICS ObservationDates WITH ROWCOUNT = 10000
manuellement afin d'obtenir le plan que Paul a démontré.
ObservationDates
donc je ne suis pas sûr de ce qui se passe avec ça. De plus, je ne peux pas non plus générer le plan généré par Paul. je vais essayer la mise à jour pour voir.
CREATE STATISTICS [_WA_Sys_00000008_2FCF1A8A] ON [dbo].[Observation_2010]([StationStateCode]) WITH STATS_STREAM = 0x01000000010000000000000000000000D4531EDB00000000D5080000000000009508000000000000AF030000AF000000020000000000000008D000340000000007000000E65DE0007DA5000076F9780000000000867704000000000000000000ABAAAA3C0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000