Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 43 Pomógł: 0 Dołączył: 13.02.2008 Ostrzeżenie: (0%)
|
witam
Czy zapytania z IN w przypadku dużej ilości danych są wydajne? Co jest lepsze - użycie takiego zapytania, w którym IN(tutaj 10,000 id-ików) operujące na dużej ilości danych czyli sprawdzajace czy id (10,000 id-ików) znajduje się w np 1mln rekordów, czy lepiej jest zrobić zapytanie po ID zapisać wynik do tablicy a potem po pobraniu porównywać czy ID jest zgodny z tym pobranym i wtedy go wyświetlić? Która opcja jest lepsza gdy dodatkowo dane trzeba posortować? chodzi mi o zapytania typu; SELECT * FROM products, ... WHERE pc.catID IN (4, 8, 9, 10, 11, 12, 13, 14, ...) AND .... |
|
|
|
![]() |
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 340 Pomógł: 49 Dołączył: 3.07.2009 Skąd: Rzeszów Ostrzeżenie: (0%)
|
Według moich doświadczeń silnik mysql radzi sobie bardzo dobrze z przykładem, który podałeś (liczby stałoprzecinkowe w in)
Jeżeli na tej kolumnie będzie index powinno być dobrze.... myślę, że lepiej niż 1M powtórzeń pętli ........chociaż nigdy nie próbowałem wsadzić 10k liczb w nawias :] To będzie wątek warty obserwacji (IMG:style_emoticons/default/smile.gif) |
|
|
|
Post
#3
|
|
|
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D |
To zależy jak się ma liczba elementów w IN w odniesieniu do wszystkich. A nuż jest ich tak dużo, że sensowniejsza jest inwersja i użycie NOT IN (IMG:style_emoticons/default/smile.gif) Wszystko rozbija się jedynie o proporcję wybranych do wszystkich. Ogólnie jednak także duże ilości w bardzo dużym zestawie dadzą pewne przyspieszenie i takie podejście ma sens. Sam pamiętam jak w jednym z zapytań do serwisu jechało ich kilka tysięcy, ale było ono generowane query builderem w kohanie jako zastępnik ORDER BY rand() i skok wydajności (co nie jest dziwne) był znaczny.
|
|
|
|
![]() ![]() |
|
Aktualny czas: 24.12.2025 - 15:38 |