Há todos os tipos de coisas que podem estar acontecendo.

Primeiro, Ivan G. está certo de que os parâmetros de conexão e as opções SET podem ser diferentes entre o SSMS e seu cliente ASP.NET. Isso é algo que vale a pena investigar no Profiler, se você tiver acesso a ele.

Segundo, se você executou sua consulta várias vezes seguidas no SSMS, é possível que os resultados estejam sendo armazenados em cache e é por isso que ela é executada tão rápido no SSMS. Se ele for executado lentamente na primeira vez que você abrir o SSMS e tentar executá-lo, mas depois acelerar, isso é um sinal de que há armazenamento em cache.

Quanto ao motivo pelo qual adicionar uma cláusula extra a uma junção pode atrasar as coisas, é difícil dizer por que sem saber mais sobre suas tabelas, mas não é impossível que isso possa ter feito isso. Existe um índice sobre BATCH_INGR que inclui tanto FACTORY e INGR_CODE ? Você pode precisar de um agora que está incluindo INGR_CODE em suas condições de associação.

A melhor maneira de descobrir é observar o plano de consulta com e sem o INGR_CODE cláusula e veja como ela difere. O valor do custo para uma consulta é maior do que para a outra? Existem varreduras de tabela onde não havia antes? Uma busca de índice se transformou em uma varredura de índice?