Korzyści z Common Table Expression (CTE)?

Z msdn :

W przeciwieństwie do tabeli pochodnej, CTE może być samo-referencyjne i może być wielokrotnie przywoływane w tym samym zapytaniu.

Używam CTE dość często, ale nigdy nie zastanawiałem się głęboko nad korzyściami z ich używania.

Jeśli wielokrotnie odwołuję się do CTE w tym samym zapytaniu:

• Czy jest jakaś korzyść z wydajności?
• Jeśli wykonuję samodzielne połączenie, czy SQL Server przeskanuje tabele docelowe dwukrotnie?

Z reguły CTE NIGDY nie poprawi wydajności .

CTE jest zasadniczo widokiem jednorazowym. Brak przechowywanych dodatkowych statystyk, indeksów itp. Działa jako skrót dla podkwerendy.

Moim zdaniem można je ŁATWO nadużywać (w mojej pracy widzę dużo nadużywania kodu). Oto kilka dobrych odpowiedzi, ale jeśli chcesz odwołać się do czegoś więcej niż jeden raz lub jest to więcej niż kilkaset tysięcy wierszy, umieść to w #temptabeli zamiast tego i zindeksuj.

Oprócz rekurencji jednym z miejsc, w którym uważam, że CTE są niezwykle przydatne, jest tworzenie złożonych zapytań sprawozdawczych. Korzystam z serii CTE, aby uzyskać fragmenty potrzebnych mi danych, a następnie łączę się w ostatecznym wyborze. Uważam, że są łatwiejsze w utrzymaniu niż robienie tego samego z wieloma tabelami pochodnymi lub 20 złączeniami, i mogę być bardziej pewny, że zwraca prawidłowe dane bez efektu wielu rekordów ze względu na wiele relacji w wszystkie różne połączenia. Dam szybki przykład:

;WITH Conferences (Conference_id)
AS 
(select  m.Conference_id
FROM mydb.dbo.Conference m 
WHERE client_id = 10
    and Conference_id in 
            (select Conference_id from mydb.dbo.Expense 
            where amount <>0
            and amount is not null)
     )
--select * from Conferences
,MealEaters(NumberMealEaters, Conference_id, AttendeeType)
AS
(Select count(*) as NumberMealEaters, m.Conference_id,  AttendeeType 
from mydb.dbo.attendance ma 
join Conferences m on m.Conference_id = ma.Conference_id
where (ma.meals_consumed>0 or meals_consumed is null)and attended = 1
group by m.Conference_id)
--select * from MealEaters

,Expenses (Conference_id,expense_date, expenseDescription,  RecordIdentifier,amount)
AS
(select Conference_id,max(expense_date) as Expense_date, expenseDescription,  RecordIdentifier,sum(amount) as amount
    FROM
        (SELECT Conference_id,expense_date,  amount, RecordIdentifier
        FROM mydb.dbo.Expense
        WHERE  amount <> 0 
            and Conference_id IN 
            (SELECT  Conference_id
            FROM mydb.dbo.Conferences ) 
        group by Conference_id, RecordIdentifier) a
)
--select * from Expenses
Select m.Conference_id,me.NumberMealEaters, me.AttendeeType, e.expense_date,         e.RecordIdentifier,amount
from Conferences m
join mealeaters me on m.Conference_id = me.Conference_id
join expenses e on e.Conference_id = m.Conference_id

Tak więc, oddzielając różne części informacji, które chcesz, możesz sprawdzić każdą część osobno (używając skomentowanych wyborów, odkomentowując każdą z osobna i biegając tylko do tego wyboru) i jeśli musisz zmienić koszt obliczenia (w tym przykładzie) łatwiej jest je znaleźć niż wtedy, gdy wszystkie są połączone razem w jedno ogromne zapytanie. Oczywiście faktyczne zapytania raportowe, w których używam tego, są na ogół znacznie bardziej skomplikowane niż w przykładzie.

Jak zawsze to zależy, ale są przypadki, w których wydajność jest znacznie poprawiona. Widzę to w instrukcjach INSERT INTO SELECT, w których używasz CTE dla zaznaczenia, a następnie używasz go w INSERT INTO. Może to mieć związek z włączeniem RCSI dla bazy danych, ale w tych czasach, gdy wybrano bardzo niewiele, może to nieco pomóc.