Tills tabellstrukturen och förväntat resultat exempeldata inte tillhandahålls, här är några snabba saker jag ser som kan förbättras (en del av dem nämns redan av andra ovan):
- WHILE Loop är också en markör. Så att byta till while loop kommer inte att göra saker snabbare.
- Använd markören LOCAL FAST_FORWARD om du inte behöver spåra en post bakåt. Detta skulle göra exekveringen mycket snabbare.
-
Ja, jag håller med om att ett SET-baserat tillvägagångssätt skulle vara det snabbaste i de flesta fall, men om du måste lagra mellanliggande resultatuppsättning någonstans, skulle jag föreslå att du använder en temporär tabell istället för en tabellvariabel. Temp-tabellen är "mindre ondska" mellan dessa 2 alternativ. Här är några anledningar till varför du bör försöka undvika att använda en tabellvariabel:
- Eftersom SQL Server inte skulle ha någon tidigare statistik på tabellvariabeln under byggandet av exekveringsplanen, kommer den alltid att anse att endast en post skulle returneras av tabellvariabeln under konstruktionen av exekveringsplanen. Och följaktligen skulle Storage Engine bara tilldela så mycket RAM-minne för exekvering av frågan. Men i verkligheten kan det finnas miljontals poster som tabellvariabeln kan ha under körning. Om det händer, skulle SQL Server tvingas spilla data till hårddisken under körning (och du kommer att se massor av PAGEIOLATCH i sys.dm_os_wait_stats) vilket gör frågorna mycket långsammare.
- Ett sätt att bli av med ovanstående problem skulle vara genom att tillhandahålla satsnivåtips OPTION (RECOMPILE) i slutet av varje fråga där ett tabellvärde används. Detta skulle tvinga SQL Server att konstruera exekveringsplanen för dessa frågor varje gång under körning och mindre minnesallokeringsproblem kan undvikas. Men nackdelen med detta är:SQL Server kommer inte längre att kunna dra fördel av en redan cachad exekveringsplan för den lagrade proceduren och skulle kräva omkompilering varje gång, vilket skulle försämra prestandan i viss utsträckning. Så om du inte vet att data i den underliggande tabellen ändras ofta eller att själva den lagrade proceduren inte körs ofta, rekommenderas inte detta tillvägagångssätt av Microsofts MVP:er.