Mam podstawową siatkę z włączonym stronicowaniem w mojej aplikacji internetowej. Ta siatka jest zapełniana danymi SQL za pośrednictwem interfejsu Web API z wykorzystaniem Dapper. W moim kontrolerze API uruchamiam dwa osobne zapytania: jeden do wyodrębnienia wierszy (które są wyświetlane w mojej siatce) i jeden do uzyskania całkowitej liczby rekordów (które będą wyświetlane w moich kontrolkach stronicowania). I to działa. Jednak staram się zoptymalizować moje zapytania.Czy mogę pobrać wiersze stronicowane i liczbę całkowitą w jednym zapytaniu?
My pierwsze zapytanie, które wyodrębnia wierszy, zwraca tylko 50 rzędów w czasie (przy użyciu OFFSET
i FETCH
, uzyskując przywoławcze
SELECT DISTINCT T_INDEX.*
FROM T_INDEX
INNER JOIN T_INDEXCALLER ON T_INDEX.IndexId = T_INDEXCALLER.IndexId
WHERE... --a fairly complex WHERE statement
ORDER BY CallTime DESC
OFFSET (@offset) ROWS FETCH NEXT 50 ROWS ONLY
Drugie zapytanie wydobywa liczbę wszystkich rzędach ale wykorzystuje te same stoły, te same przyłącza, a tym samym WHERE
klauzuli.
SELECT COUNT(DISTINCT T_INDEX.IndexId)
FROM T_INDEX
INNER JOIN T_INDEXCALLER ON T_INDEX.IndexId = T_INDEXCALLER.IndexId
WHERE... --the same fairly complex WHERE statement
Jak powiedziałem, to działa i t około 2,5 sekundy na jedno zapytanie, łącznie 5+ sekund. Opóźnienie to nie koniec świata, za wszelką cenę, ale chciałbym skrócić ten czas o połowę.
Chciałem wiedzieć, czy istnieje sposób na odzyskanie 50 wierszy i, aby uzyskać całkowitą liczbę WSZYSTKICH wierszy w ramach jednego zapytania. Zdaję sobie sprawę, że te dwa pytania robią dwie odrębne rzeczy. Ale moim zdaniem jest to, że "może" być sposobem na dostosowanie tych dwóch zapytań i połączenie ich w jedno, ponieważ tabele, łączenia i klauzula WHERE
są identyczne między tymi dwoma.
Myślę, że to może być to, czego szukam. Podczas mojej pierwszej pary wygląda na to, że działa świetnie. Zamierzam zrobić jeszcze kilka poprawek. –