Chúng tôi có kho dữ liệu với số lượng bản ghi khá lớn (10-20 triệu hàng) và thường chạy các truy vấn đếm các bản ghi giữa các ngày nhất định hoặc đếm các bản ghi với các cờ nhất định, ví dụ:
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
Hiệu suất không tệ, nhưng có thể tương đối chậm chạp (có thể là 10 giây trên bộ đệm lạnh).
Gần đây tôi phát hiện ra rằng tôi có thể sử dụng GROUP BYtrong các chế độ xem được lập chỉ mục và vì vậy đã thử một cái gì đó tương tự như sau
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
);
Do đó, hiệu suất của truy vấn đầu tiên của tôi hiện là <100ms và chế độ xem & chỉ mục kết quả là <100k (mặc dù số lượng hàng của chúng tôi lớn, phạm vi ngày và ID cờ có nghĩa là chế độ xem này chỉ chứa 1000-2000 hàng).
Tôi nghĩ rằng có lẽ điều này sẽ làm giảm hiệu suất ghi vào bảng Widget, nhưng không - hiệu suất của việc chèn và cập nhật vào bảng này không bị ảnh hưởng nhiều như tôi có thể nói (cộng với, là kho dữ liệu mà bảng này được cập nhật không thường xuyên dù sao)
Đối với tôi, điều này dường như quá tốt để trở thành sự thật - phải không? Tôi cần phải cẩn thận khi sử dụng các chế độ xem được lập chỉ mục theo cách này?
SELECTvàCREATE VIEWkịch bản là sai, vì tôi tin làCREATE INDEXkịch bản của bạn .