Ci sono tutti i tipi di cose che potrebbero succedere.
Innanzitutto, Ivan G. ha ragione sul fatto che i parametri di connessione e le opzioni SET potrebbero essere diversi tra SSMS e il client ASP.NET. È qualcosa che vale la pena esaminare in Profiler, se hai accesso ad esso.
In secondo luogo, se hai eseguito la query più volte di seguito in SSMS, è possibile che i risultati vengano memorizzati nella cache ed è per questo che funziona così velocemente in SSMS. Se funziona lentamente la prima volta che apri SSMS e provi a eseguirlo, ma poi accelera, è un segno che è in corso la memorizzazione nella cache.
Per quanto riguarda il motivo per cui l'aggiunta di una clausola in più a un join potrebbe rallentare le cose, è difficile dire perché senza saperne di più sulle tue tabelle, ma non è impossibile che ciò possa averlo fatto. Esiste un indice su BATCH_INGR che include entrambi FACTORY e INGR_CODE ? Potresti averne bisogno ora che stai includendo INGR_CODE nelle tue condizioni di partecipazione.
Il modo migliore per scoprirlo è guardare il piano di query con e senza INGR_CODE clausola e vedere come differisce. La cifra di costo per una query è maggiore rispetto all'altra? Ci sono scansioni di tabelle dove prima non c'erano? Una ricerca dell'indice si è trasformata in una scansione dell'indice?
