Dokud nebude poskytnuta struktura tabulky a vzorová data očekávaných výsledků, zde je několik rychlých věcí, které lze zlepšit (některé z nich již zmiňují jiní výše):
- WHILE Loop je také kurzor. Přepnutím na smyčku while se tedy věci nezrychlí.
- Pokud nepotřebujete zpětně sledovat záznam, použijte kurzor LOCAL FAST_FORWARD. Tím by bylo provádění mnohem rychlejší.
-
Ano, souhlasím s tím, že přístup založený na SET by byl ve většině případů nejrychlejší, ale pokud musíte někde uložit mezilehlou sadu výsledků, navrhoval bych použít dočasnou tabulku místo proměnné tabulky. Temp table je mezi těmito 2 možnostmi „menší zlo“. Zde je několik důvodů, proč byste se měli pokusit vyhnout použití proměnné tabulky:
- Vzhledem k tomu, že SQL Server nebude mít žádné předchozí statistiky o proměnné tabulky během vytváření plánu provádění, bude vždy uvažovat, že proměnná tabulky by během vytváření plánu provádění vrátila pouze jeden záznam. A podle toho by Storage Engine přidělil pouze tolik paměti RAM pro provedení dotazu. Ve skutečnosti však mohou existovat miliony záznamů, které může proměnná tabulky během provádění ukládat. Pokud k tomu dojde, SQL Server by byl nucen během provádění přesunout data na pevný disk (a v sys.dm_os_wait_stats uvidíte spoustu PAGEIOLATCH), což zpomalí dotazy.
- Jedním způsobem, jak se výše uvedeného problému zbavit, by bylo poskytnutí nápovědy na úrovni příkazu OPTION (RECOMPILE) na konci každého dotazu, kde je použita hodnota tabulky. To by přinutilo SQL Server vytvořit plán provádění těchto dotazů pokaždé během běhu a lze se vyhnout menšímu problému s přidělením paměti. Nevýhodou tohoto však je:SQL Server již nebude moci využívat plán provádění již uložený v mezipaměti pro tuto uloženou proceduru a vyžadoval by pokaždé rekompilaci, což by do určité míry zhoršilo výkon. Pokud tedy nevíte, že se data v podkladové tabulce často mění nebo samotná uložená procedura není často prováděna, tento přístup Microsoft MVP nedoporučují.