Kwerenda z parametrami wolna w aplikacji ale szybka w SSMS

Witam wszystkich,
Problem udało się co prawda rozwiązać, ale miłoby było zrozumieć dlaczego nastąpił w pierwszej kolejności oraz dlaczego to rozwiązanie zadziałało.
Zakładam, że ów rozwiązanie może być przypadkiem i nie mieć nic wspólnego z problemem ale po jego zastosowaniu "u mnie działa".

Czy ktoś mądrzejszy może podzielić się ze mną wiedzą i podpowiedzieć o co chodzi?

Problem następujący. (proszę zignorować jakoś kodu bo wiem, ze posysa)

  public static DataTable SQL_ClosedCases(DateTime _from, DateTime _to)
        {
            #region 
            string SQL_query = @"
                   select * from myCoolTable
		                    where Date1 >= cast(@DateFrom as date) and Date1  <= cast(@DateTo as date) -- Działa tak samo szybko jak w SSMS
                                   -- where Date1 >= @Date and Date1  <= @DateTo  -- nie działa, wczytuje się 10+ min

                           ";

            #endregion

            SqlConnection SQLconn = new SqlConnection(ConnectionInfo.ConnectionString);
            SqlCommand sqlCommand = new SqlCommand(SQL_query);

            sqlCommand.Parameters.Add("@DateFrom", SqlDbType.Date);
            sqlCommand.Parameters["@DateFrom"].Value = _from;
            sqlCommand.Parameters.Add("@DateTo", SqlDbType.Date);
            sqlCommand.Parameters["@DateTo"].Value = _to;

            sqlCommand.CommandTimeout = 60000;

            try
            {
                Impersonation.RunAsUser(Auxiliary_Functions.credentials, LogonType.NewCredentials, () =>
                {
                    SQLconn.Open();
                });

                sqlCommand.Connection = SQLconn;
            }
            catch (Exception e)
            {
                MessageBox.Show("Connection failed! " + e.ToString());
                return null;
            }

            SqlDataAdapter sda = new SqlDataAdapter(sqlCommand);
            DataTable dt = new DataTable();
            sda.Fill(dt);
            SQLconn.Close();
            return dt;
        }

Typ kolumny na Serwerze Date1 jest Date. Więc parametry też ustawiam jako SqlDbType.Date.
W moim ograniczonym rozumieniu to powinno wystarczyć niestety wczytywanie wyniku jest bardzo długie.
Szalonym pomysłeł w kwerendzie użyłem cast więc zmiana z:
where Date1 >= @DateFrom and Date1 <= @DateTo
na:
where Date1 >= cast(@DateFrom as date) and Date1 <= cast(@DateTo as date)

I teraz działa tak samo szybko jak w SSMS.
Tych dni kiedy myślę, że w kij nie nadaje się do tej roboty zaczyna być znacznie więcej :-(.

Ktoś? Coś?

W myśl zasady nie znam się, ale się wypowiem jedyne co mi się w oczy rzuciło to w zapytaniu masz "where Date1 >= @Date" nie @DateFrom

Masz jakiś problem, ze robisz rzutowanie SQL ?

I drugie, nachodzi mnie podejrzenie, że w Studio piszesz minimalnie inaczej (sam bym w studio z palca testował "inaczej")

Wieki temu w Postgresie, nie posiadałem tej wiedzy a ją wywalczyłem, rzutowanie mogła zabijać wydajność.

Przy pierwotnym zapisie silnik wyszukiwania SQL castuje Date1 każdego rekordu z typu Date na DateTime, stąd dużo wolniejsze działanie. Kiedy odwróciłeś sytuacje i scastowałeś parametr z DateTime na Date, to śmiga bez problemu.

Masz jakieś indeksy na tabeli założone?

A spróbuj może pod

sqlCommand.Parameters["@DateFrom"].Value

podstawić samą datę w stringu w formacie yyyy-mm-dd

Hm Hm...
zawsze żyłem w przeświadczeniu, że format możesz dopiero podać jak konwertujesz do stringa.
Nie mniej to dało mi pomysł na .Date:

            sqlCommand.Parameters["@DateFrom"].Value = _from.Date;          
            sqlCommand.Parameters["@DateTo"].Value = _to.Date;

Jedyne co mi przychodzi do głowy to, że on się krztusi jak dostaje DateTime.

No nic.. ważne że działa.
Dziękuję wszystkim

Ciekawe zagadnienie, sprawdziłem to u siebie do SQL idzie zawsze tak samo:

exec sp_executesql N'select * from tab where  dt >= @DateFrom and dt  <= @DateTo ',N'@DateFrom date,@DateTo date',@DateFrom='2021-10-20',@DateTo='2021-10-20'

Żeby faktycznie stwierdzić, musialbyś sprawdzić profilerem co faktycznie idzie do bazy