Par défaut la ligne de commande dans la requête SELECT - SQL Server 2008 vs SQL 2012

Notre équipe a récemment mis à jour notre base de données à partir de SQL Server 2008, SQL Server 2012. Une modification de rupture que nous avons remarquée est dans l'ordre par défaut des lignes retournées par la requête SELECT, c'est à dire quand une clause ORDER BY explicite n'est pas spécifié.

Comme par MSDN, SQL Server 2012 ne permet pas de garantir l'ordre des lignes retournées à moins d'une clause ORDER BY est spécifié.

Nous avons 2500+ des procédures stockées sur 5 bases de données qui ont des instructions SELECT sans une clause ORDER BY, et il sera un important effort d'ajouter la clause ORDER BY manuellement pour reproduire le comportement de SQL Server 2008. Est-il un paramètre ou un moyen plus rapide de faire cela?

L'autre option, qui n'a pas été explorée, est de revenir à SQL Server 2008. La difficulté serait-ce?

Il n'y a pas une telle chose comme le "défaut de ligne de commande". Des lignes dans une table relationnelle sont PAS triés. Moins vous spécifiez un order by le SGBD est libre de retourner dans aucun commander, il semble en forme. Votre code a été rompu dès le début. La seule solution sensée à votre problème est de mordre la balle et de modifier le code pour utiliser un order by Vous avez de la chance, ce bug n'a pas montré plus tôt.
Bien SQL 2008 est le même, il n'est pas garanti "par défaut" ligne de commande
Essayez d'utiliser clustured et non clustured indice, si vous avez déjà une clé primaire dans la table, vous n'avez pas à vous soucier de clustured en tant que par défaut de la clé primaire est clustured index.
ORDER BY ne doit être pertinente dans SELECT requêtes. (à moins que vous faire des choses vraiment stupides comme LIMIT 1 dans les sous-requêtes, ou de sortir de curseur boucles)
Pourquoi l'utilisation de LIMIT une chose stupide, @joop?

OriginalL'auteur Channs | 2014-10-07

  1. 41

    Vous avez besoin de revenir en arrière et ajouter ORDER BY clauses de votre code, car sans eux, l'ordre n'est jamais garanti. Vous avez été "chanceux" dans le passé que vous avez toujours obtenu le même ordre, mais il n'était pas parce que SQL Server 2008 garantie il en, de toute façon. Il est probable qu'il a eu à faire avec votre index ou de la façon dont les données sont stockées sur le disque.

    Si vous avez déménagé dans un nouvel hôte lorsque vous avez mis à niveau la différence dans la configuration matérielle seule pourrait avoir changé la façon dont vos requêtes à exécuter. Ne pas mentionner le fait que le nouveau serveur serait recalculé les statistiques sur les tables et le SQL Server 2012 optimiseur de requête probablement fait les choses un peu différemment que dans SQL Server 2008.

    C'est une erreur que vous pouvez compter sur l'ordre d'un jeu de résultats dans SQL sans indiquer explicitement l'ordre que vous souhaitez. Les résultats SQL JAMAIS ont une commande, vous pouvez compter sur sans l'aide d'un ORDER BY clause. SQL est construit autour de la théorie des ensembles. Les résultats de la requête sont essentiellement des jeux (ou multi-ensembles).

    Itzik Ben-Gan donne une bonne description de la théorie des ensembles par rapport à SQL dans son livre Microsoft SQL Server 2012 T-SQL les Fondamentaux

    De la théorie des ensembles, qui sont nées avec le mathématicien Georg Cantor, est
    l'une des mathématiques branches sur lesquelles le modèle relationnel est
    en fonction. Chantre de la définition d'un ensemble suit:

    Par un "ensemble", nous entendons toute la collection de M en un ensemble de précis, distinct
    les objets de m (qui sont appelés les "éléments" de M) de notre perception ou
    de notre pensée. - Joseph W. Dauben et Georg Cantor (Princeton
    University Press, 1990)

    Après une explication approfondie des termes de la définition de Itzik continue ensuite en disant:

    Ce Chantre de la définition d'un ensemble de feuilles est probablement aussi important
    comme ce qu'il comprend. Notez que la définition ne mentionne pas tout
    l'ordre au sein de l'ensemble des éléments. L'ordre dans lequel les éléments sont
    listé n'est pas importante. La notation formelle pour l'inscription d'éléments
    utilise des accolades: {a, b, c}. Car l'ordre n'a pas de pertinence, vous pouvez
    exprimer le même ensemble {b, a, c} ou {b, c, a}. Sauter en avant à la
    un ensemble d'attributs (appelés colonnes dans SQL) qui composent l'en-tête d'un
    la relation (appelé une table dans SQL), un élément est censé être
    identifié par son nom - pas de position ordinale. De même, considérer l'ensemble
    des n-uplets (appelées lignes par SQL) qui composent le corps de la relation;
    un élément est identifié par ses valeurs clés de ne pas en position. De nombreux
    les programmeurs ont du mal à s'adapter à l'idée que, à l'égard
    l'interrogation de tables, il n'y a pas d'ordre entre les lignes. En d'autres termes,
    une requête sur une table peut retourner des lignes dans toute commande à moins que vous
    demander explicitement que les données soient triées de manière spécifique, peut-être
    pour les besoins de la présentation.

    Mais indépendamment de la définition académique de la un jeu, même la mise en œuvre de SQL server n'a jamais garanti l'ordre dans les résultats. Cette MSDN blog à partir de 2005 par un membre de l'optimiseur de requête de l'équipe indique que vous ne devriez pas compter sur le bon de commande à partir d'intermédiaire en opérations.

    La réorganisation des règles et de ne pas violer cette hypothèse (et le faire
    quand il n'est pas pratique pour vous, le développeur ;). S'il vous plaît comprendre
    que lorsque nous réorganiser les opérations de trouver un moyen plus efficace de plan, nous pouvons
    cause le comportement de la commande de changement pour les nœuds intermédiaires dans le
    d'arbre en arbre. Si vous avez mis une opération dans l'arbre, qui suppose une
    particulier intermédiaire de la commande, il peut se casser.

    Ce blog par Conor Cunningham (Architecte, SQL Server Core Engine) "Pas de Ceinture de sécurité - Attend Commande sans ORDONNANCE EN" est sur SQL Server 2008. Il dispose d'une table avec 20k lignes avec un seul indice qui semble toujours revenir rangées dans le même ordre. L'ajout d'un ORDER BY pour la requête n'a même pas changer le plan de l'exécution, de sorte qu'il n'est pas comme l'ajout d'un en fait la requête plus cher si l'optimiseur se rend compte qu'il n'en a pas besoin. Mais une fois qu'il ajoute un autre 20k lignes à la table soudainement la requête de changement de plan, et maintenant il utilise le parallélisme et les résultats ne sont plus commandés!

    La partie la plus difficile ici est qu'il n'existe aucun moyen raisonnable pour les externes
    l'utilisateur de savoir si un plan de changement . L'espace de tous les plans est énorme
    et fait mal à la tête à réfléchir. SQL Server de l'optimiseur va changer
    les plans, même pour les requêtes simples, si assez de changement des paramètres.
    Vous pouvez avoir de la chance et ne pas avoir un changement de plan, ou vous pouvez tout simplement pas
    penser à ce problème et ajouter une COMMANDE PAR.

    Si vous avez besoin de plus convaincant viens de lire ces messages:

    Cet ordre n'est pas garanti. De nombreux facteurs peuvent influer sur l'ordre des résultats de la requête et vous ne pouvez pas anticiper tous. Vous pourriez avoir de la chance pour un certain temps et peut-être jamais. Mais l'ajout de la ORDER BY clause n'aura aucun impact sur les performances si l'optimiseur de requête se rend compte qu'il n'en a pas besoin. Est-il la peine de courir le risque que les choses vont se casser brusquement juste parce que vous n'avez pas envie de mettre un ORDER BY sur votre requête?
    Je ne sais pas quelle est la signification de vous voir dans le fait que votre requête simple avec une table d'index renvoie les lignes dans l'ordre que vous attendez. N où ai-je dit qu'il ne viendra jamais dans l'ordre que vous attendez. Relisez la dernière citation dans ma réponse à partir de l'un de SQL Server Architectes. Sans le ORDER BY clause de l'ordre de votre résultat est susceptible de changer à tout moment, pour de nombreuses raisons que vous ne pouvez pas savoir quand cela va arriver. Ce que vous dites, c'est de mauvais conseils et ne doivent pas être utilisés dans un système de production. Ne comptez pas sur des indices de référence pour la commande. Si vous avez besoin d'un jeu de résultats commandés utiliser un ORDER BY
    C'est un fait que vous ne pouvez pas garantir l'ordre de tri sans spécifier une clause ORDER BY. Même si elle arrive à 99,99% du temps, ce n'est pas à 100%, c'est juste de la chance, et simpliste de cas de test. S'il vous plaît changer votre commentaire. Il est très important que d'autres personnes lisant cette réponse de comprendre cela, si vous comptez sur ordre de tri, puis vous devez explicitement l'ordre de vos résultats. Il n'est pas "travailler dans SQL 2016". Il ne fonctionne pas dans toutes les éditions, il est tout à fait à la requête du moteur de décider afin que les résultats sont retournés, sauf si vous commandez PAR. Vos commentaires ici seulement confondre les gens.
    Supprimé mes commentaires. Clause Order by est incontournable pour une précision de 100%.

    OriginalL'auteur Mike D.