Sự khác biệt hiệu năng lớn của SQL bằng cách sử dụng SELECT TOP x ngay cả khi x cao hơn nhiều hàng đã chọn

Question

Tôi đang chọn một số hàng từ hàm bảng có giá trị nhưng đã tìm thấy sự khác biệt hiệu suất lớn không thể giải thích bằng cách đặt SELECT TOP trong truy vấn.

SELECT col1, col2, col3 etc 
FROM  dbo.some_table_function 
WHERE col1 = @parameter 
--ORDER BY col1 

mất tối đa 5 hoặc 6 phút để hoàn thành.

Tuy nhiên

SELECT TOP 6000 col1, col2, col3 etc 
FROM  dbo.some_table_function 
WHERE col1 = @parameter 
--ORDER BY col1 

hoàn thành trong khoảng 4 hoặc 5 giây.

Điều này sẽ không làm tôi ngạc nhiên nếu tập hợp dữ liệu được trả lại là rất lớn, nhưng truy vấn cụ thể liên quan đến trả về ~ 5000 hàng trong số 200.000.

Vì vậy, trong cả hai trường hợp, toàn bộ bảng được xử lý, khi SQL Server tiếp tục kết thúc để tìm kiếm 6000 hàng mà nó sẽ không bao giờ nhận được. Tại sao sự khác biệt lớn sau đó? Đây có phải là một cái gì đó để làm với cách SQL Server phân bổ không gian với dự đoán kích thước thiết lập kết quả (TOP 6000 do đó cho nó một yêu cầu thấp được phân bổ dễ dàng hơn trong bộ nhớ)? Có ai khác đã chứng kiến ​​một cái gì đó như thế này?

Cảm ơn

Answer 1

Các hàm có giá trị bảng có thể có thời gian thực hiện phi tuyến tính.

Hãy xem xét chức năng tương đương cho truy vấn này:

SELECT (
     SELECT SUM(mi.value) 
     FROM mytable mi 
     WHERE mi.id <= mo.id 
     ) 
FROM mytable mo 
ORDER BY 
     mo.value 

Truy vấn này (cho phép tính chạy SUM) là nhanh ngay từ đầu và chậm ở cuối, vì trên mỗi hàng từ mo nó nên tổng hợp tất cả các các giá trị trước đó đòi hỏi phải tua lại các rowsource.

Thời gian thực hiện để tính SUM cho mỗi hàng tăng khi số hàng tăng lên.

Nếu bạn thực hiện mytable đủ lớn (ví dụ: 100,000 hàng, như trong ví dụ của bạn) và chạy truy vấn này, bạn sẽ thấy rằng phải mất nhiều thời gian.

Tuy nhiên, nếu bạn áp dụng TOP 5000 cho truy vấn này, bạn sẽ thấy rằng nó hoàn thành nhanh hơn nhiều so với 1/20 thời gian cần thiết cho toàn bộ bảng.

Rất có thể, điều gì đó tương tự cũng xảy ra trong trường hợp của bạn.

Để nói điều gì đó chắc chắn hơn, tôi cần xem định nghĩa hàm.

Cập nhật:

SQL Server có thể đẩy các vị từ vào hàm.

Ví dụ, tôi vừa tạo TVF này:

CREATE FUNCTION fn_test() 
RETURNS TABLE 
AS 
RETURN (
     SELECT * 
     FROM master 
     ); 

Các truy vấn này: quét

SELECT * 
FROM fn_test() 
WHERE name = @name 

SELECT TOP 1000 * 
FROM fn_test() 
WHERE name = @name 

năng suất khác nhau kế hoạch thực hiện (một trong những đầu tiên sử dụng cụm, điều thứ hai sử dụng một chỉ mục tìm kiếm với a TOP)

Answer 2

Không nhất thiết phải là toàn bộ bảng được xử lý nếu col1 có chỉ mục.

Tối ưu hóa SQL sẽ chọn có sử dụng chỉ mục hay không. Có lẽ "TOP" của bạn đang buộc nó sử dụng chỉ mục.

Nếu bạn đang sử dụng Trình phân tích truy vấn MSSQL (Tên thoát tôi) nhấn Ctrl-K. Điều này sẽ hiển thị kế hoạch thực hiện cho truy vấn thay vì thực hiện nó. Di chuyển qua các biểu tượng sẽ hiển thị mức sử dụng IO/CPU, tôi tin.

Tôi đặt cược một người đang sử dụng tìm kiếm chỉ mục, trong khi người khác thì không.

Nếu bạn có khách hàng chung: SET SHOWPLAN_ALL ON; GO chọn ...; go

xem http://msdn.microsoft.com/en-us/library/ms187735.aspx để biết chi tiết.

Answer 3

Bạn có thể chạy vào một cái gì đó đơn giản như bộ nhớ đệm ở đây - có lẽ (vì lý do gì) truy vấn "TOP" được lưu trong bộ nhớ cache? Sử dụng một chỉ số mà người khác không phải là?

Trong mọi trường hợp, cách tốt nhất để làm dịu sự tò mò của bạn là kiểm tra toàn bộ kế hoạch thực hiện cho cả hai truy vấn. Bạn có thể làm điều này ngay trong SQL Management Console và nó sẽ cho bạn biết chính xác những gì các hoạt động đang được hoàn thành và bao lâu mỗi dự đoán sẽ thực hiện.

Tất cả triển khai SQL đều kỳ quặc theo cách riêng của chúng - SQL Server cũng không ngoại lệ. Những loại "whaaaaaa ?!" những khoảnh khắc khá phổ biến. ; ^)

Answer 4

TOP của bạn không có ORDER BY, vì vậy nó đơn giản giống như SET ROWCOUNT 6000 trước. Một ORDER BY sẽ yêu cầu tất cả các hàng được đánh giá đầu tiên và sẽ mất nhiều thời gian hơn.

Nếu dbo.some_table_function là bảng nội tuyến có giá trị udf, thì nó chỉ đơn giản là macro được mở rộng để trả về 6000 hàng đầu tiên được đề cập không theo thứ tự cụ thể.

Nếu udf có giá trị đa, thì đó là hộp đen và sẽ luôn lấy toàn bộ tập dữ liệu trước khi lọc. Tôi không nghĩ rằng điều này đang xảy ra.

Không liên quan trực tiếp, nhưng another SO question on TVFs

Answer 5

Tôi nghĩ Quassnois' gợi ý có vẻ rất đáng tin cậy. Bằng cách thêm TOP 6000, bạn đang ngầm đưa cho trình tối ưu hóa một gợi ý rằng một tập hợp con nhỏ 200.000 hàng sẽ được trả về. Trình tối ưu hóa sau đó sử dụng chỉ mục tìm kiếm thay vì quét chỉ mục nhóm hoặc quét bảng.

Một giải thích có thể khác có thể lưu vào bộ nhớ cache, như Jim davis gợi ý. Điều này khá dễ dàng để loại trừ bằng cách chạy lại các truy vấn. Hãy thử chạy một với TOP 6000 đầu tiên.

Answer 6

Tôi đã có cùng một vấn đề, một truy vấn đơn giản tham gia năm bảng trở về 1000 hàng mất hai phút để hoàn thành. Khi tôi thêm "TOP 10000" vào nó, nó hoàn thành trong chưa đầy một giây. Hóa ra chỉ số nhóm trên một trong các bảng bị phân mảnh nhiều.

Sau khi tạo lại chỉ mục, truy vấn hiện đã hoàn tất sau chưa đầy một giây.