Es gibt alle möglichen Dinge, die vor sich gehen könnten.
Erstens hat Ivan G. Recht, dass Verbindungsparameter und SET-Optionen zwischen SSMS und Ihrem ASP.NET-Client unterschiedlich sein können. Es lohnt sich, sich das im Profiler anzusehen, wenn Sie Zugriff darauf haben.
Zweitens:Wenn Sie Ihre Abfrage mehrmals hintereinander in SSMS ausgeführt haben, werden die Ergebnisse möglicherweise zwischengespeichert, weshalb sie in SSMS so schnell ausgeführt wird. Wenn es langsam läuft, wenn Sie SSMS zum ersten Mal öffnen und versuchen, es auszuführen, aber dann schneller wird, ist das ein Zeichen dafür, dass Caching stattfindet.
Warum das Hinzufügen einer zusätzlichen Klausel zu einem Join die Dinge verlangsamen könnte, ist schwer zu sagen, ohne mehr über Ihre Tabellen zu wissen, aber es ist nicht unmöglich, dass dies der Fall gewesen sein könnte. Gibt es einen Index über BATCH_INGR das beinhaltet sowohl FACTORY und INGR_CODE ? Möglicherweise benötigen Sie jetzt einen, da Sie INGR_CODE einfügen in Ihren Teilnahmebedingungen.
Der beste Weg, dies herauszufinden, ist, sich den Abfrageplan mit und ohne INGR_CODE anzusehen Klausel und sehen, wie es sich unterscheidet. Ist die Kostenzahl für eine Abfrage größer als für die andere? Gibt es Tabellenscans, wo vorher keine waren? Hat sich eine Indexsuche in einen Indexscan verwandelt?
