Les données sont physiquement stockées par un index clusterisé, qui est généralement la clé primaire, mais n'a pas à l'être.
Les données en SQL ne sont pas garanties d'avoir un ordre sans une clause ORDER BY. Vous devez toujours spécifier une clause ORDER BY lorsque vous avez besoin que les données soient dans un ordre particulier. Si le tableau est déjà trié de cette façon, l'optimiseur n'effectuera aucun travail supplémentaire, il n'y a donc aucun mal à l'avoir ici.
Sans clause ORDER BY, le SGBDR peut renvoyer des pages mises en cache correspondant à votre requête pendant qu'il attend que les enregistrements soient lus à partir du disque. Dans ce cas, même s'il existe un index sur la table, les données peuvent ne pas arriver dans l'ordre de l'index. (Notez que ce n'est qu'un exemple - je ne sais pas ou ne pense même pas qu'un SGBDR réel le fera, mais c'est un comportement acceptable pour une implémentation SQL.)
MODIFIER
Si vous avez un impact sur les performances lors du tri par rapport à l'absence de tri, vous triez probablement sur une colonne (ou un ensemble de colonnes) qui n'a pas d'index (cluster ou autre). Étant donné qu'il s'agit d'une série chronologique, vous effectuez peut-être un tri en fonction du temps, mais l'index clusterisé se trouve sur le bigint principal. SQL Server ne sait pas que les deux augmentent de la même manière, il doit donc tout trier.
Si la colonne de temps et la colonne de clé primaire sont liées par ordre (l'une augmente si et seulement si l'autre augmente ou reste la même), triez plutôt par la clé primaire. S'ils ne sont pas liés de cette manière, déplacez l'index clusterisé de la clé primaire vers la ou les colonnes sur lesquelles vous triez.
