Il y a une limite à la quantité d'optimisation que vous pouvez faire sur les clauses ORDER BY. Le principal qui aide parfois est d'avoir un index sur le bon ensemble de colonnes dans le bon ordre. Ainsi, pour votre exemple, un index (simple, composite) sur :
average_price_per_month ASC, phone_price_guestimate DESC, contract_length ASC
peut aider, mais l'optimiseur peut toujours décider qu'il est préférable d'utiliser un autre index pour traiter les termes de filtre dans la requête, puis il triera lui-même les données ainsi sélectionnées. Notez qu'à moins que l'index ne fournisse les données exactement dans l'ordre de tri correct et que l'utilisation de l'index n'accélère globalement la requête, l'optimiseur ne l'utilisera pas. Un index sur une seule des colonnes à trier est un avantage limité pour l'optimiseur, et il n'utilisera normalement pas un tel index.
Une question à considérer :
- À quelle vitesse la requête s'exécute-t-elle sans la clause ORDER BY ?
Cela vous donne une mesure très directe du coût du tri. Vous mentionnez 20 ms sans commande et 120 ms avec commande, donc ORDER BY est moyennement cher. La question suivante pourrait être "Pouvez-vous surpasser son tri dans votre application ?". Vous pourrez peut-être le faire, mais le package de tri dans un SGBD est généralement assez bien optimisé et vous devrez probablement travailler dur pour le battre.
