Istnieje limit optymalizacji, którą można wykonać w klauzulach ORDER BY. Podstawowym, który czasami pomaga, jest indeksowanie właściwego zestawu kolumn we właściwej kolejności. Tak więc, dla twojego przykładu, (pojedynczy, złożony) indeks na:
average_price_per_month ASC, phone_price_guestimate DESC, contract_length ASC
może pomóc, ale optymalizator może nadal zdecydować, że lepiej jest użyć innego indeksu do obsługi terminów filtru w zapytaniu, a następnie sam posortuje wybrane w ten sposób dane. Należy zauważyć, że o ile indeks nie dostarcza danych w dokładnie prawidłowej kolejności posortowania, a użycie indeksu ogólnie przyspiesza zapytanie, optymalizator nie będzie ich używał. Indeks tylko jednej z kolumn do posortowania jest ograniczoną korzyścią dla optymalizatora i zwykle nie używa takiego indeksu.
Jedno pytanie do rozważenia:
- Jak szybko wykonuje zapytanie bez klauzuli ORDER BY.
Daje to bardzo bezpośredni pomiar kosztów sortowania. Wspominasz 20 ms bez zamawiania i 120 ms z zamawianiem, więc ORDER BY jest umiarkowanie drogi. Następne pytanie może brzmieć:„Czy możesz przewyższyć go w swojej aplikacji?”. Możesz to zrobić, ale pakiet sortowania w DBMS jest zwykle dość dobrze zoptymalizowany i prawdopodobnie będziesz musiał ciężko pracować, aby go pokonać.
