Witam wszystkich.
Mam problem jak rozwikłać optymalne rozwiązanie dotyczące odpowiedniego posortowania wyników z bazy danych.
Przykładowa struktura:
id | dost | pozycja
1 3 1
2 1 6
3 6 9
4 2 7
5 1 3
6 2 4
i chciałbym:
Czy końcowy wynik wg id by wyglądał tak:
5, 2, 6, 4, 1, 3
Pomożecie stworzyć mi optymalne zapytanie ?
select * from tabela order by dost, pozycja
Właściwie każdy DBMS posiada coś takiego jak query planner, co generalnie odpowiada za optymalizowanie zapytań. Na przykład, jeśli masz zdefiniowane kilka indeksów na tabeli, planner będzie próbował wybrać ten, który maksymalnie przyspieszy dane zapytanie i zdecyduje, czy w ogóle którykolwiek indeks pasuje do zapytania.
Nie ma potrzeby np. próbować hakować zapytania, by przyspieszyć "zwykłe" sortowanie kolumn - zostaw to plannerowi. Gdybyś miał bardziej złożone zapytania, mógłbyś kombinować, jak je przepisać by ułatwić robotę plannerowi (prawdopodobnie upraszczając je i wyrzucając brzydkie haki), ale przy prostym sortowaniu po 2 kolumnach jedyna sensowna rzecz, która przychodzi mi do głowy, to wybrać odpowiedni indeks - przykładowo, btree porządkuje elementy więc może pomóc przy sortowaniu, hash index niekoniecznie. Przykład z PostgreSQL
Tak jak napisał @superdurszlak. Tu nie ma co optymalizować. Można tylko indeksy założyć. W przypadku PostgreSQLa wystarczy na każdą kolumnę założyć osobny indeks. W przypadku Oracla trzeba założyć jeden indeks z kolumnami w dobrej kolejności (takiej jak w zapytaniu). Oczywiście przed i po założeniu indeksów należy zmierzyć czasy. BTW jeśli danych jest mało to możliwe że żadnej różnicy w wydajności i tak nie zauważysz. BTW2 to w zasadzie powinno być podstawowe pytanie. Ile tych danych masz że chcesz tak prostą strukturę optymalizować (pół Tera?) i ile czasu trwa przeszukanie obecnie niezoptymalizowanej tabeli?
Z nadawaniem indeksów trzeba uważać to się opłaca przy dużych, często przeszukiwanych danymi
nowyworek napisał(a):
Z nadawaniem indeksów trzeba uważać to się opłaca przy dużych, często przeszukiwanych danymi
Małych, rzadko przeszukiwanych zbiorów danych nikt znający sie na rzeczy chyba nie chce optymalizować?
KamilAdam napisał(a):
nowyworek napisał(a):
Z nadawaniem indeksów trzeba uważać to się opłaca przy dużych, często przeszukiwanych danymi
Małych, rzadko przeszukiwanych zbiorów danych nikt znający sie na rzeczy chyba nie chce optymalizować?
Często widziałem, jak ludzie rzucają tymi indeksami jakby jutra nie było
nowyworek napisał(a):
KamilAdam napisał(a):
nowyworek napisał(a):
Z nadawaniem indeksów trzeba uważać to się opłaca przy dużych, często przeszukiwanych danymi
Małych, rzadko przeszukiwanych zbiorów danych nikt znający sie na rzeczy chyba nie chce optymalizować?
Często widziałem, jak ludzie rzucają tymi indeksami jakby jutra nie było
Po prostu trzeba wiedzieć co się robi i nic więcej.
Mieć świadomość, że gdy będziemy mieć miliony rekordów indeksy spowalniają każdy insert, zabierają miejsce na dysku (To akurat zazwyczaj nie jest duży problem).
Indeksy zwyczajnie rozwiązują problem ze słaba wydajnością zapytań, gdy występują dziesiątki tysięcy rekordów, więc nie tyle jest to problem rzucaniem indeksami a po prostu dobrym sposobem rozwiązywania problemu nieefektywnych zapytań.