C'è un limite alla quantità di ottimizzazione che puoi fare sulle clausole ORDER BY. Quello principale che a volte aiuta è avere un indice sull'insieme corretto di colonne nell'ordine corretto. Quindi, per il tuo esempio, un indice (singolo, composito) su:
average_price_per_month ASC, phone_price_guestimate DESC, contract_length ASC
potrebbe essere d'aiuto, ma l'ottimizzatore potrebbe comunque decidere che è meglio utilizzare qualche altro indice per gestire i termini del filtro nella query e quindi ordinerà i dati così selezionati. Tieni presente che, a meno che l'indice non fornisca i dati esattamente nell'ordine ordinato e l'utilizzo dell'indice acceleri la query in generale, l'ottimizzatore non lo utilizzerà. Un indice solo su una delle colonne da ordinare è un vantaggio limitato per l'ottimizzatore e normalmente non utilizzerà tale indice.
Una domanda da considerare:
- Quanto velocemente viene eseguita la query senza la clausola ORDER BY.
Questo ti dà una misurazione molto diretta del costo dello smistamento. Menzioni 20 ms senza ordinazione e 120 ms con ordinazione, quindi ORDER BY è moderatamente costoso. La domanda successiva potrebbe essere "Riesci a superare il suo ordinamento nella tua applicazione?". Potresti essere in grado di farlo, ma il pacchetto di ordinamento in un DBMS è generalmente abbastanza ben ottimizzato e probabilmente dovrai lavorare sodo per superarlo.
