Има ограничение за това колко оптимизация можете да направите на клаузите ORDER BY. Основният, който понякога помага, е наличието на индекс върху правилния набор от колони в правилния ред. И така, за вашия пример, (единичен, съставен) индекс на:
average_price_per_month ASC, phone_price_guestimate DESC, contract_length ASC
може да помогне, но оптимизаторът все пак може да реши, че е по-добре да използва някакъв друг индекс, за да се справи с условията на филтъра в заявката и след това сам ще сортира така избраните данни. Обърнете внимание, че освен ако индексът не предоставя данните в точно правилния сортиран ред и използването на индекса не ускорява цялостната заявка, оптимизаторът няма да го използва. Индекс само на една от колоните за сортиране е ограничена полза за оптимизатора и той обикновено няма да използва такъв индекс.
Един въпрос за разглеждане:
- Колко бързо се изпълнява заявката без клаузата ORDER BY.
Това ви дава много директно измерване на разходите за сортиране. Споменавате 20 ms без поръчка и 120 ms с поръчка, така че ORDER BY е умерено скъп. Следващият въпрос може да бъде „Можете ли да надминете неговия вид във вашето приложение?“. Може да успеете да направите това, но пакетът за сортиране в СУБД обикновено е доста добре оптимизиран и вероятно ще трябва да работите усилено, за да го победите.
