Hay un límite en la cantidad de optimización que puede hacer en las cláusulas ORDER BY. El principal que a veces ayuda es tener un índice en el conjunto correcto de columnas en el orden correcto. Entonces, para su ejemplo, un índice (único, compuesto) en:
average_price_per_month ASC, phone_price_guestimate DESC, contract_length ASC
podría ayudar, pero el optimizador aún podría decidir que es mejor usar algún otro índice para tratar con los términos de filtro en la consulta y luego ordenará los datos así seleccionados. Tenga en cuenta que, a menos que el índice proporcione los datos exactamente en el orden correcto y el uso del índice acelere la consulta en general, el optimizador no lo usará. Un índice en solo una de las columnas que se van a ordenar es un beneficio limitado para el optimizador y normalmente no utilizará dicho índice.
Una pregunta a considerar:
- Qué tan rápido se ejecuta la consulta sin la cláusula ORDER BY.
Eso le da una medida muy directa del costo de clasificación. Usted menciona 20 ms sin pedido y 120 ms con pedido, por lo que ORDER BY es moderadamente costoso. La siguiente pregunta podría ser "¿Puede superar a su tipo en su aplicación?". Es posible que pueda hacerlo, pero el paquete de clasificación en un DBMS generalmente está bastante bien optimizado y es probable que tenga que trabajar duro para superarlo.
