Beneficios de la expresión de tabla común (CTE)?

De msdn :

A diferencia de una tabla derivada, un CTE puede ser autorreferenciado y puede ser referenciado varias veces en la misma consulta.

Estoy usando mucho los CTE, pero nunca he pensado profundamente en los beneficios de usarlos.

Si hago referencia a un CTE varias veces en la misma consulta:

• ¿Hay algún beneficio de rendimiento?
• Si estoy haciendo una autounión, ¿SQL Server escaneará las tablas de destino dos veces?

Como regla general, un CTE NUNCA mejorará el rendimiento .

Un CTE es esencialmente una vista desechable. No hay estadísticas adicionales almacenadas, ni índices, etc. Funciona como una abreviatura para una subconsulta.

En mi opinión, pueden ser FÁCILMENTE sobreutilizados (veo mucho uso excesivo en el código en mi trabajo). Aquí hay algunas buenas respuestas, pero si necesita referirse a algo más de una vez, o son más de unos cientos de miles de filas, póngalo en una #temptabla e indícelo.

Un lugar además de la recursión donde encuentro que los CTE son increíblemente útiles es al crear consultas de informes complejas. Utilizo una serie de CTE para obtener fragmentos de los datos que necesito y luego los combino en la selección final. Encuentro que son más fáciles de mantener que hacer lo mismo con muchas tablas derivadas o 20 uniones y encuentro que puedo estar más seguro de que devuelve los datos correctos sin efecto de registros múltiples debido a las relaciones de uno a muchos en Todas las diferentes combinaciones. Déjame darte un ejemplo rápido:

;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

Entonces, al separar los diferentes fragmentos de información que desea, puede verificar cada parte individualmente (usando las selecciones comentadas, descomentando cada una individualmente y solo corriendo hasta esa selección) y si necesita hacer un cambio en el gasto cálculo (en este ejemplo), es más fácil de encontrar que cuando se mezclan en una consulta masiva. Por supuesto, las consultas de informes reales para las que uso esto son generalmente mucho más complicadas que el ejemplo.

Como siempre, depende, pero hay casos en los que el rendimiento mejora considerablemente. Lo veo con las instrucciones INSERT INTO SELECT donde usa un CTE para la selección y luego lo usa en INSERT INTO. Es posible que tenga que ver con la configuración de RCSI para la base de datos, pero para aquellos momentos en que se selecciona muy poco, puede ayudar bastante.