Er kunnen allerlei dingen aan de hand zijn.
Ten eerste heeft Ivan G. gelijk dat verbindingsparameters en SET-opties kunnen verschillen tussen SSMS en uw ASP.NET-client. Dat is iets dat de moeite van het onderzoeken waard is in Profiler, als je er toegang toe hebt.
Ten tweede, als je je query meerdere keren achter elkaar in SSMS hebt uitgevoerd, is het mogelijk dat de resultaten in de cache worden opgeslagen en dat het daarom zo snel werkt in SSMS. Als het de eerste keer dat je SSMS opent langzaam werkt en het probeert uit te voeren, maar dan versnelt, is dat een teken dat er caching aan de gang is.
Wat betreft waarom het toevoegen van een extra clausule aan een join de zaken zou kunnen vertragen, het is moeilijk te zeggen waarom zonder meer te weten over je tabellen, maar het is niet onmogelijk dat dat het had kunnen doen. Is er een index over BATCH_INGR dat omvat zowel FACTORY en INGR_CODE ? Je hebt er misschien een nodig nu je INGR_CODE . opneemt in uw deelnamevoorwaarden.
De beste manier om erachter te komen is door naar het queryplan te kijken met en zonder de INGR_CODE clausule en kijk hoe het verschilt. Is het kostencijfer voor de ene zoekopdracht groter dan voor de andere? Zijn er tafelscans waar er voorheen niet waren? Is een indexzoekopdracht veranderd in een indexscan?