Há um limite para a quantidade de otimização que você pode fazer nas cláusulas ORDER BY. O principal que às vezes ajuda é ter um índice no conjunto correto de colunas na ordem correta. Então, para o seu exemplo, um índice (único, composto) em:
average_price_per_month ASC, phone_price_guestimate DESC, contract_length ASC
pode ajudar, mas o otimizador ainda pode decidir que é melhor usar algum outro índice para lidar com os termos de filtro na consulta e, em seguida, ele mesmo classificará os dados assim selecionados. Observe que, a menos que o índice forneça os dados exatamente na ordem de classificação correta e o uso do índice acelere a consulta geral, o otimizador não o usará. Um índice em apenas uma das colunas a serem classificadas é um benefício limitado para o otimizador e normalmente não usará esse índice.
Uma questão a considerar:
- Qual a velocidade de execução da consulta sem a cláusula ORDER BY.
Isso lhe dá uma medida muito direta do custo de classificação. Você menciona 20 ms sem pedido e 120 ms com pedido, então o ORDER BY é moderadamente caro. A próxima pergunta pode ser "Você pode superar sua classificação em seu aplicativo?". Você pode fazer isso, mas o pacote de classificação em um DBMS geralmente é bastante bem otimizado e é provável que você tenha que trabalhar duro para vencê-lo.
