sql >> Databasteknik >  >> RDS >> Sqlserver

Varför CTE (Common Table Expressions) i vissa fall saktar ner frågor jämfört med temporära tabeller i SQL Server

Svaret är enkelt.

SQL Server förverkligas inte CTE:er. Det infogar dem, som du kan se av utförandeplanerna.

Andra DBMS kan implementera det annorlunda, ett välkänt exempel är Postgres, som faktiskt realiserar CTE:er (det skapar i huvudsak tillfälliga tabeller för CTEs bakom huven).

Huruvida explicit materialisering av intermediära resultat i explicita temporära tabeller är snabbare beror på frågan.

I komplexa frågor kan omkostnaderna för att skriva och läsa mellanliggande data till temporära tabeller kompenseras av effektivare enklare exekveringsplaner som optimeraren kan generera.

Å andra sidan, i Postgres är CTE ett "optimeringsstängsel" och motorn kan inte skjuta predikat över CTE-gränsen.

Ibland är ett sätt bättre, ibland ett annat. När frågekomplexiteten växer över en viss tröskel kan en optimerare inte analysera alla möjliga sätt att bearbeta data och den måste lösa något. Till exempel i vilken ordning man ska gå med i tabellerna. Antalet permutationer växer exponentiellt med antalet tabeller att välja mellan. Optimeraren har begränsad tid på sig att skapa en plan, så den kan göra ett dåligt val när alla CTE:er är infogade. När du manuellt delar upp komplexa frågor i mindre enklare måste du förstå vad du gör, men optimeraren har en bättre chans att skapa en bra plan för varje enkel fråga.



  1. VÄLJ från 3:e kommatecken i strängen

  2. AttributeError:'UUID'-objektet har inget attribut 'replace' när du använder backend-agnostisk GUID-typ

  3. Är det möjligt att ställa in standardschema från anslutningssträngen?

  4. SQL-pivotdata med dynamisk lista med kolumner