Jaka jest naturalna kolejność zwracanych wyników selecta gdy nie mam ustawionego paramtru "ORDER"?
Domyślam się że jest to kolejność występowania tych danych w tabeli?
Chodzi o sytuację gdy np. klucz główny to ciąg znaków (np LOGIN użytkownika w tabeli użytkowników) i rekordy (użytkownicy) nie są do tabeli wpisani według sortowania alfabetycznego LOGINU tylko przemieszani (jak to bywa życiu). Czy selecty robione w takiej tabeli wyszukujące po kilku użytkowników (całe rekordy "SELECT * FROM users WHERE") albo tylko dane z pojedynczych kolumn z tej tabeli (np tylko select daty urodzeń użytkowników z lat 1990-1995 " SELECT users.date FROM users WHERE") zawsze zwrócą wyniki posortowane domyślnie według ich wystąpienia w bazie?
0
0
losowa
0
- Nie jest ustalona i wynika właściwie tylko ze struktury fizycznego ułożenia danych na dysku i sposobu w jaki optymalizator kosztowy postanowi to odczytać. Może to wynikać na przykład z indeksów. Zauważ że jedna "tabela" może na dysku być bardzo mocno poszatkowana, pomiędzy różne tablespace. To ze masz dwa rekordy o podobnych ID nie znaczy że są gdziekolwiek obok siebie na dysku.
- Nie. Nie masz pewności że kolejność będzie taka sama. Jeśli gdzieś są założone indeksy to juz w ogóle ;] Optymalizator kosztowy moze raz na jakiś czas czytać to nawet od tyłu jak mu sie tak zachce ;)
0
To masakra. Jeżeli będę chciał pobierać dane w partiach (stronnicowanie) selectami z LIMIT to kolejne zapytania mogą powtarzać wybrana wcześniej rekordy.
Np. Jeżeli wyszukuję userów z tablicy users kolejnymi zapytaniami:
SELECT * FROM users WHERE users.country='Polska' LIMIT 0,20;
i
SELECT * FROM users WHERE users.country='Polska' LIMIT 20,20;
niektóre rekordy będące wynikiem obu zapytań mogą się powtórzyć ?
0
Mogą ;] Musisz to sortować.
0
Czyli:
SELECT * FROM users ORDER BY users.date WHERE users.country='Polska' LIMIT 0,20;
i
SELECT * FROM users ORDER BY users.date WHERE users.country='Polska' LIMIT 20,20;
załatwi sprawę (stronnicowanie niepowtarzających się rekordów)?
Tylko do tej pory myślałem że najpierw jest wykonywany SELECT a dopiero potem wynik jest ustawiany według warunku ORDER BY.
A tu wychodzi na to że ORDER wpływa na SELECT'a
0
SELECT * FROM users WHERE users.country='Polska' ORDER BY users.date LIMIT 0,20;
ORDER BY powinien być po WHERE.
0
- Nie jest ustalona i wynika właściwie tylko ze struktury fizycznego ułożenia danych na dysku i sposobu w jaki optymalizator kosztowy postanowi to odczytać. Może to wynikać na przykład z indeksów. Zauważ że jedna "tabela" może na dysku być bardzo mocno poszatkowana, pomiędzy różne tablespace. To ze masz dwa rekordy o podobnych ID nie znaczy że są gdziekolwiek obok siebie na dysku.
- Nie. Nie masz pewności że kolejność będzie taka sama. Jeśli gdzieś są założone indeksy to juz w ogóle ;] Optymalizator kosztowy moze raz na jakiś czas czytać to nawet od tyłu jak mu sie tak zachce
Shalom napisał(a):
Musisz to sortować.
@Shalom: Nie wydaje Ci się, że to ... głupie .. zachowanie, które powinno być wyeliminowane na etapie projektowania systemu bazodanowego? No bo idąc Twoim rozumowaniem - trzeba więc sortować wg WSZYSTKICH w zasadzie kolumn (tj. można poprzestać na kolumnie z wartościami unikalnymi, jeżeli taka jest), żeby mieć pewność, że na kolejnej stronie wyniki się nie powtórzą. A widziałeś gdzieś taki system, który:
- sortuje wg wszystkich kolumn
- nie sortuje wg wszystkich kolumn ale ma działające stronicowanie
Zakładam, że na codzień spotykasz się z tym drugim przypadkiem.
Moje doświadczenia opierają się tylko na MySQL, który zwraca elementy w miarę losowo, jeżeli było dużo zmian w tabeli - ale dopóki tabeli nie modyfikuję - kolejność jest już stała. I to mi się wydaje normalnym zachowaniem - dostęp do tych samych danych jest w tej samej kolejności.
0
Moje doświadczenia opierają się tylko na MySQL, który zwraca elementy w miarę losowo, jeżeli było dużo zmian w tabeli - ale dopóki tabeli nie modyfikuję - kolejność jest już stała. I to mi się wydaje normalnym zachowaniem - dostęp do tych samych danych jest w tej samej kolejności.
To jest bzdura ;) Optymalizator może wygenerować dwa różne plany wykonania zapytania nawet dla identycznego stanu tabel, na przykład ze względu na inne równolegle przetwarzane transakcje (czyli zwykle locki! no chyba ze używasz SZBD z multiwersyjną izolacją transakcji), albo ze względu na stan obciążenia bazy zapytaniami. Poleganie na tym że "powinny być w tej samej kolejności" jest błędem projektowym. Zresztą jaką masz niby pewność ze w chwili kiedy sobie przeglądasz tabelę ktoś nie doda nowego rekordu? A masz tam na przykład indeks hashujący i ci SZBD akurat postanowi przebudować ten indeks? ;]
Powiem więcej: nawet samo order by wcale nie gwarantuje ze wszystko zadziała poprawnie! Bo nie masz pewności że algorytm którego używa twoja baza danych jest stabilny! Jeśli sortujesz po nazwisku, a masz 10 Kowalskich to nie masz pewności że za każdym razem dostaniesz tych kowalskich w tej samej kolejności sortując tylko po ich nazwisku ;]
Jak ten problem rozwiązać? Można na przykład pobrać wszystko i cacheować sobie wynik zapytania a przy kolejnych przejściach podawać do widoku tą część która użytownika interesuje.
0
Jeśli sortujesz po nazwisku, a masz 10 Kowalskich to nie masz pewności że za każdym razem dostaniesz tych kowalskich w tej samej kolejności sortując tylko po ich nazwisku ;]
Dlatego właśnie wspomniałem - wg tego co mówisz to ratuje nas tylko sortowanie po wszystkich (nieunikalnych, bądź min. 1 unikalnej) kolumnach.
Pobieranie wszystkiego to czasem przesada, gdyby ktoś coś takiego rozważał to zalecam raczej wybranie samego primary keya (tablica samych primary keyów nie będzie zbyt duża, w przeciwieństwie do dużej tabeli z wszystkimi kolumnami) i potem wg tego wybierać rekordy dalej
0
Dlatego właśnie wspomniałem - wg tego co mówisz to ratuje nas tylko sortowanie po wszystkich (nieunikalnych, bądź min. 1 unikalnej) kolumnach.
Sortujesz po swojej kolumnie a potem po kluczu ;) Innej rady nie ma. Jasne że jak masz tabelę która ma dużo pól to można wtedy mysleć o jakimś wydajniejszym wyciąganiu danych, ale tak czy siak nie wolno polegać na kolejności rekordów bez sortowania.