Trier par id utilise probablement un balayage d'index clusterisé lors de la commande par datetime utilise le tri ou la recherche d'index.
Ces deux méthodes sont plus lentes qu'un balayage d'index clusterisé.
Si votre table est regroupée par id , cela signifie essentiellement qu'il est déjà trié. Les enregistrements sont contenus dans un B+Tree qui a une liste liée reliant les pages dans id ordre. Le moteur doit simplement parcourir la liste chaînée pour obtenir les enregistrements classés par id .
Si l'id s ont été insérés dans un ordre séquentiel, cela signifie que l'ordre physique des lignes correspondra à l'ordre logique et que le parcours de l'index clusterisé sera encore plus rapide.
Si vous souhaitez que vos enregistrements soient triés par datetime , il y a deux options :
- Prenez tous les enregistrements du tableau et triez-les. La lenteur est évidente.
- Utiliser l'index sur
datetime. L'index est stocké dans un espace séparé du disque, cela signifie que le moteur doit faire la navette entre les pages d'index et les pages de table dans une boucle imbriquée. C'est aussi plus lent.
Pour améliorer l'ordre, vous pouvez créer un index de couverture séparé sur datetime :
CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …)
, et incluez toutes les colonnes que vous utilisez dans votre requête dans cet index.
Cet index est comme un cliché instantané de votre table mais avec des données triées dans un ordre différent.
Cela permettra de se débarrasser des recherches de clés (puisque l'index contient toutes les données) qui feront un tri par datetime aussi vite que ça sur id .
Mise à jour :
Un nouveau billet de blog sur ce problème :
