우리는 상당히 많은 레코드 수 (10 ~ 2 천만 행)를 가진 데이터웨어 하우스를 가지고 있으며 특정 날짜 사이의 레코드를 계산하거나 특정 플래그로 레코드를 계산하는 쿼리를 실행하는 경우가 있습니다.
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성능은 좋지 않지만 상대적으로 느려질 수 있습니다 (콜드 캐시에서 10 초 정도).
최근 GROUP BY에 인덱싱 된 뷰에서 사용할 수 있음을 발견 하고 다음과 비슷한 것을 시도했습니다.
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
);결과적으로 첫 번째 쿼리의 성능은 이제 <100ms이고 결과 뷰 및 인덱스는 <100k입니다 (행 수는 크지 만 날짜 및 플래그 ID 범위는이 뷰에 1000-2000 개의 행만 포함됨).
아마도 이것이 위젯 테이블에 대한 쓰기 성능을 저하시킬 수 있다고 생각했지만 아니오-이 테이블에 대한 삽입 및 업데이트 성능은 내가 알 수있는 한 거의 영향을받지 않습니다 (또한이 테이블은 데이터웨어 하우스이므로 드물게 업데이트됩니다) 어쨌든)
나에게 이것은 사실 이기에는 너무 좋은 것 같습니다. 이 방법으로 인덱싱 된 뷰를 사용할 때주의해야 할 사항은 무엇입니까?
@MarkSinkinson 사과, 가상 테이블에 유효한 SQL을 작성하는 것은 어렵다는 사실이 밝혀졌습니다.
—
Justin
MAX에 대한 고급 뷰, 자체 또는 외부 조인을 포함하거나 다른 뷰를 참조하는 뷰 인덱싱과 같은 고급 뷰를 원할 때 '실제로 너무 좋았습니다'는 SQL Server의 모든 뷰가 아닙니다. docs.microsoft.com/en-us/sql/relational-databases/views/…를 허용 했습니다 . 그래서 나는 항상 지나치게 야심을 가지고 일을 축소해야합니다. 그러나 더 간단한 집계에서는 정말 훌륭합니다. 심지어 SUM도 지원됩니다.
—
Simon_Weaver
SELECT과CREATE VIEW대본이 잘못되었습니다CREATE INDEX.