Có sự khác biệt về hiệu suất giữa CTE, Truy vấn phụ, Bảng tạm thời hoặc Biến bảng không?

Trong câu hỏi SO xuất sắc này , sự khác biệt giữa CTEvà sub-queriesđã được thảo luận.

Tôi muốn hỏi cụ thể:

Trong trường hợp nào thì mỗi cách sau đây hiệu quả hơn / nhanh hơn?

• CTE
• Truy vấn phụ
• Bảng tạm thời
• Bảng biến

Theo truyền thống, tôi đã sử dụng rất nhiều temp tablestrong việc phát triển stored procedures- vì chúng dường như dễ đọc hơn nhiều truy vấn phụ đan xen.

Non-recursive CTEs đóng gói các bộ dữ liệu rất tốt và rất dễ đọc, nhưng có những trường hợp cụ thể mà người ta có thể nói rằng chúng sẽ luôn hoạt động tốt hơn không? hoặc đó là một trường hợp phải luôn luôn loay hoay với các tùy chọn khác nhau để tìm ra giải pháp hiệu quả nhất?

BIÊN TẬP

Gần đây tôi đã được thông báo rằng về mặt hiệu quả, các bảng tạm thời là lựa chọn đầu tiên tốt vì chúng có biểu đồ liên quan tức là thống kê.

SQL là ngôn ngữ khai báo, không phải là ngôn ngữ thủ tục. Đó là, bạn xây dựng một câu lệnh SQL để mô tả các kết quả mà bạn muốn. Bạn không nói cho công cụ SQL biết cách thực hiện công việc.

Theo nguyên tắc chung, nên để công cụ SQL và trình tối ưu hóa SQL tìm ra kế hoạch truy vấn tốt nhất. Có nhiều nỗ lực trong nhiều năm để phát triển một công cụ SQL, vì vậy hãy để các kỹ sư làm những gì họ biết cách làm.

Tất nhiên, có những tình huống mà kế hoạch truy vấn không tối ưu. Sau đó, bạn muốn sử dụng gợi ý truy vấn, cơ cấu lại truy vấn, cập nhật số liệu thống kê, sử dụng bảng tạm thời, thêm chỉ mục, v.v để có hiệu suất tốt hơn.

Đối với câu hỏi của bạn. Về mặt lý thuyết, hiệu năng của CTE và các truy vấn con phải giống nhau vì cả hai đều cung cấp cùng một thông tin cho trình tối ưu hóa truy vấn. Một điểm khác biệt là CTE được sử dụng nhiều lần có thể dễ dàng xác định và tính toán một lần. Các kết quả sau đó có thể được lưu trữ và đọc nhiều lần. Thật không may, SQL Server dường như không tận dụng được phương pháp tối ưu hóa cơ bản này (bạn có thể gọi đây là loại bỏ truy vấn con chung).

Các bảng tạm thời là một vấn đề khác, bởi vì bạn đang cung cấp thêm hướng dẫn về cách chạy truy vấn. Một sự khác biệt chính là trình tối ưu hóa có thể sử dụng số liệu thống kê từ bảng tạm thời để thiết lập kế hoạch truy vấn của nó. Điều này có thể dẫn đến tăng hiệu suất. Ngoài ra, nếu bạn có một CTE (truy vấn con) phức tạp được sử dụng nhiều lần, thì việc lưu trữ nó trong một bảng tạm thời thường sẽ giúp tăng hiệu suất. Truy vấn chỉ được thực hiện một lần.

Câu trả lời cho câu hỏi của bạn là bạn cần phải chơi xung quanh để có được hiệu suất mà bạn mong đợi, đặc biệt đối với các truy vấn phức tạp được chạy thường xuyên. Trong một thế giới lý tưởng, trình tối ưu hóa truy vấn sẽ tìm thấy đường dẫn thực hiện hoàn hảo. Mặc dù nó thường như vậy, bạn có thể tìm ra cách để có hiệu suất tốt hơn.

Không có quy tắc. Tôi thấy các CTE dễ đọc hơn và sử dụng chúng trừ khi chúng thể hiện một số vấn đề về hiệu năng, trong trường hợp đó tôi điều tra vấn đề thực tế thay vì đoán rằng CTE là vấn đề và cố gắng viết lại bằng cách sử dụng một cách tiếp cận khác. Vấn đề thường có nhiều vấn đề hơn là cách tôi chọn để tuyên bố ý định của mình với truy vấn.

Chắc chắn có những trường hợp khi bạn có thể làm sáng tỏ CTE hoặc xóa các truy vấn con và thay thế chúng bằng bảng #temp và giảm thời lượng. Điều này có thể do nhiều thứ khác nhau, chẳng hạn như số liệu thống kê cũ, thậm chí không thể có được số liệu thống kê chính xác (ví dụ: tham gia vào hàm có giá trị bảng), song song hoặc thậm chí không thể tạo kế hoạch tối ưu do tính phức tạp của truy vấn ( trong trường hợp phá vỡ nó có thể mang lại cơ hội chiến đấu tối ưu hóa). Nhưng cũng có trường hợp I / O liên quan đến việc tạo bảng #temp có thể vượt trội hơn các khía cạnh hiệu suất khác có thể làm cho hình dạng kế hoạch cụ thể sử dụng CTE kém hấp dẫn.

Thành thật mà nói, có quá nhiều biến để đưa ra câu trả lời "đúng" cho câu hỏi của bạn. Không có cách nào có thể dự đoán được khi nào một truy vấn có thể nghiêng về cách tiếp cận này hay cách khác - chỉ cần biết rằng, về mặt lý thuyết, cùng một ngữ nghĩa cho một CTE hoặc một truy vấn con sẽ thực hiện chính xác như nhau. Tôi nghĩ rằng câu hỏi của bạn sẽ có giá trị hơn nếu bạn trình bày một số trường hợp không đúng - có thể là bạn đã phát hiện ra một giới hạn trong trình tối ưu hóa (hoặc đã phát hiện ra một câu hỏi đã biết) hoặc có thể là các truy vấn của bạn không tương đương về mặt ngữ nghĩa hoặc cái đó chứa một yếu tố cản trở tối ưu hóa.

Vì vậy, tôi khuyên bạn nên viết truy vấn theo cách có vẻ tự nhiên nhất đối với bạn và chỉ đi chệch hướng khi bạn phát hiện ra một vấn đề hiệu suất thực tế mà trình tối ưu hóa đang gặp phải. Cá nhân tôi xếp hạng họ CTE, sau đó truy vấn con, với bảng #temp là giải pháp cuối cùng.

#temp được mizedized và CTE thì không.

CTE chỉ là cú pháp nên về lý thuyết nó chỉ là một truy vấn con. Nó được thực thi. #temp được cụ thể hóa. Vì vậy, một CTE đắt tiền trong một phép nối được thực thi nhiều lần có thể tốt hơn trong #temp. Mặt khác, nếu đó là một đánh giá dễ dàng không được thực hiện nhưng một vài lần sau đó không xứng đáng với chi phí chung của #temp.

Có một số người trên SO không thích biến bảng nhưng tôi thích họ vì chúng được vật chất hóa và tạo nhanh hơn #temp. Đôi khi trình tối ưu hóa truy vấn làm tốt hơn với #temp so với biến bảng.

Khả năng tạo PK trên #temp hoặc biến bảng cung cấp cho trình tối ưu hóa truy vấn nhiều thông tin hơn CTE (vì bạn không thể khai báo PK trên CTE).

Chỉ có 2 điều tôi nghĩ làm cho nó LUÔN LUÔN nên sử dụng Bảng # Temp thay vì CTE là:

1. Bạn không thể đặt khóa chính trên CTE để dữ liệu được CTE truy cập sẽ phải duyệt qua từng chỉ mục trong các bảng của CTE thay vì chỉ truy cập PK hoặc Index trên bảng tạm thời.

2. Vì bạn không thể thêm các ràng buộc, chỉ mục và khóa chính vào CTE nên chúng dễ bị lỗi xâm nhập và dữ liệu xấu.

ngày hôm qua

Dưới đây là một ví dụ trong đó các ràng buộc #table có thể ngăn chặn dữ liệu xấu không phải là trường hợp trong CTE

DECLARE @BadData TABLE ( 
                       ThisID int
                     , ThatID int );
INSERT INTO @BadData
       ( ThisID
       , ThatID
       ) 
VALUES
       ( 1, 1 ),
       ( 1, 2 ),
       ( 2, 2 ),
       ( 1, 1 );

IF OBJECT_ID('tempdb..#This') IS NOT NULL
    DROP TABLE #This;
CREATE TABLE #This ( 
             ThisID int NOT NULL
           , ThatID int NOT NULL
                        UNIQUE(ThisID, ThatID) );
INSERT INTO #This
SELECT * FROM @BadData;
WITH This_CTE
     AS (SELECT *
           FROM @BadData)
     SELECT *
       FROM This_CTE;