Докато структурата на таблицата и примерните данни за очаквания резултат не бъдат предоставени, ето няколко бързи неща, които виждам, които могат да бъдат подобрени (някои от тях вече са споменати от други по-горе):
- Цикълът WHILE също е курсор. Така че преминаването към цикъл на while няма да направи нещата по-бързи.
- Използвайте курсора LOCAL FAST_FORWARD, освен ако не трябва да проследявате запис. Това би направило изпълнението много по-бързо.
-
Да, съгласен съм, че използването на подход, базиран на SET, би било най-бързият в повечето случаи, но ако трябва да съхранявате някъде междинен набор от резултати, бих предложил да използвате временна таблица вместо променлива на таблица. Временната таблица е „по-малкото зло“ между тези 2 опции. Ето няколко причини, поради които трябва да избягвате използването на променлива на таблица:
- Тъй като SQL Server няма да има никакви предварителни статистически данни за променливата на таблицата по време на изграждането на план за изпълнение, той винаги ще счита, че само един запис ще бъде върнат от променливата на таблицата по време на изграждането на плана за изпълнение. И съответно Storage Engine ще зададе само толкова RAM памет за изпълнение на заявката. Но в действителност може да има милиони записи, които променливата на таблицата може да съдържа по време на изпълнение. Ако това се случи, SQL Server ще бъде принуден да прехвърли данните на твърдия диск по време на изпълнение (и ще видите много PAGEIOLATCH в sys.dm_os_wait_stats), правейки заявките значително по-бавни.
- Един от начините да се отървете от горния проблем би бил чрез предоставяне на подсказка на ниво оператор OPTION (RECOMPILE) в края на всяка заявка, където се използва таблична стойност. Това би принудило SQL Server да изгражда плана за изпълнение на тези заявки всеки път по време на изпълнение и проблемът с разпределението на по-малко памет може да бъде избегнат. Недостатъкът на това обаче е:SQL Server вече няма да може да се възползва от вече кеширан план за изпълнение за тази съхранена процедура и ще изисква повторно компилиране всеки път, което би влошило производителността до известна степен. Така че, освен ако не знаете, че данните в основната таблица се променят често или самата съхранена процедура не се изпълнява често, този подход не се препоръчва от MVP на Microsoft.
