Nejprve se ujistěte, že správně profilujete výkon. Například spusťte dotaz dvakrát z ADO.NET a zjistěte, zda je podruhé mnohem rychlejší než poprvé. To odstraňuje režii čekání na zkompilování aplikace a nárůst infrastruktury ladění.
Dále zkontrolujte výchozí nastavení v ADO.NET a SSMS. Pokud například spustíte SET ARITHABORT OFF v SSMS, můžete zjistit, že nyní běží stejně pomalu jako při použití ADO.NET.
Jednou jsem zjistil, že SET ARITHABORT OFF v SSMS způsobilo překompilování uloženého procesu a/nebo použití jiných statistik. A najednou SSMS i ADO.NET hlásily zhruba stejnou dobu spuštění.
Chcete-li to zkontrolovat, podívejte se na plány provádění pro každé spuštění, konkrétně na tabulku syscacheobjects. Pravděpodobně budou jiné.
Spuštěním 'sp_recompile' na konkrétní uložené proceduře vynecháte přidružený plán provádění z mezipaměti, což potom SQL Serveru umožňuje vytvořit možná vhodnější plán při příštím spuštění procedury.
Nakonec můžete vyzkoušet přístup „nuke it from orbit“ a vyčistit celou mezipaměť procedur a vyrovnávací paměti pomocí SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Pokud tak učiníte před otestováním dotazu, zabráníte použití plánů provádění v mezipaměti a mezipaměti předchozích výsledků.