Nous avons un entrepôt de données avec un nombre d’enregistrements assez important (10 à 20 millions de lignes) et nous exécutons souvent des requêtes qui comptent les enregistrements entre certaines dates ou comptent des enregistrements avec certains indicateurs, par exemple
SELECT
f.IsFoo,
COUNT(*) AS WidgetCount
FROM Widgets AS w
JOIN Flags AS f
ON f.FlagId = w.FlagId
WHERE w.Date >= @startDate
GROUP BY f.IsFoo
Les performances ne sont pas terribles, mais peuvent être relativement lentes (peut-être 10 secondes sur un cache froid).
Récemment, j'ai découvert que je pouvais l'utiliser GROUP BY
dans des vues indexées et j'ai donc essayé quelque chose de similaire au suivant
CREATE VIEW TestView
WITH SCHEMABINDING
AS
SELECT
Date,
FlagId,
COUNT_BIG(*) AS WidgetCount
FROM Widgets
GROUP BY Date, FlagId;
GO
CREATE UNIQUE CLUSTERED INDEX PK_TestView ON TestView
(
Date,
FlagId
);
Par conséquent, les performances de ma première requête sont désormais <100 ms, et la vue et l'index résultants sont <100 Ko (bien que notre nombre de lignes soit élevé, la plage de dates et d'ID d'indicateur signifie que cette vue ne contient que 1000 à 2000 lignes).
Je pensais que cela réduirait peut-être les performances des écritures dans la table Widget, mais non - les performances des insertions et des mises à jour dans cette table sont à peu près inchangées pour autant que je sache (en plus, étant un entrepôt de données, cette table est mise à jour rarement. en tous cas)
Pour moi, cela semble beaucoup trop beau pour être vrai - n'est-ce pas? À quoi dois-je faire attention lorsque j'utilise des vues indexées de cette manière?
SELECT
etCREATE VIEW
sont erronés, car je pense que c'est votreCREATE INDEX
script.