Une table est-elle intrinsèquement triée par sa clé primaire? Si j'ai une table avec la clé primaire sur une colonne d'identité de BigintInty, puis-je faire confiance à ce que les requêtes renvoient toujours les données triées par la clé ou dois-je explicitement besoin d'ajouter "la commande par". La différence de performance est significative.
7 Réponses :
Les données sont physiquement stockées par index en cluster, qui est généralement la clé principale mais ne doit pas être obligée.
Les données de SQL ne sont pas garanties d'avoir une commande sans ordre par clause. Vous devez toujours spécifier une commande par clause lorsque vous avez besoin que les données soient dans un ordre particulier. Si la table est déjà triée de cette façon, l'optimiseur ne fera aucun travail supplémentaire, il n'y a donc aucun mal à l'avoir là.
Sans ordre par clause, les PDBM pourraient renvoyer des pages en cache correspondant à votre requête pendant qu'il attend que les enregistrements soient lus dans le disque. Dans ce cas, même s'il existe un indice sur la table, les données pourraient ne pas entrer dans la commande de l'indice. (Notez que ceci est juste un exemple - je ne sais pas et ne pense même même pas qu'un RDBM dans le monde réel fera cela, mais c'est un comportement acceptable pour une implémentation SQL.)
Si vous avez un impact sur la performance lors du tri lorsque vous ne triez pas, vous triez probablement sur une colonne (ou un ensemble de colonnes) qui n'a pas d'index (en regroupement ou autrement). Étant donné que c'est une série chronologique, vous pourriez être trier en fonction du temps, mais l'indice en cluster est sur la principale bégling. SQL Server ne sait pas que les deux augmentent de la même manière, il doit donc tout recourir.
Si la colonne TIME et la colonne Touche principale sont une connexion par ordre (on augmente si et uniquement si l'autre augmente ou reste la même), trier par la clé primaire. S'ils ne sont pas liés de cette façon, déplacez l'index en cluster de la clé primaire sur la ou les colonnes que vous triez.
Le premier paragraphe devrait dire "les données sont physiquement stockées par l'index en cluster ...". Tout ce que Welbog dit s'applique - juste parce qu'il est stocké physiquement [dans chaque page] dans une commande ne signifie pas que vous le récupérerez dans cet ordre. La fragmentation de disque physique peut également avoir un impact sur cela.
@Philip Kelley: changé pour refléter votre meilleur phrasé. Merci.
Je trie en fait sur la clé primaire (qui est la Bigint). Les données ont été insérées de manière ordonnée (par date).
La clé principale est-elle un indice en cluster?
La clé principale est en cluster et la clé est le champ ID (Bigint).
dans SQL Server: Non, par elle est La fonction principale de la clé principale consiste à identifier de manière unique chaque ligne de la table - mais elle n'implique pas de tri (physique) en soi.
Pas sûr des autres systèmes de base de données.
marc
Ceci peut être spécifique à la mise en œuvre, mais MySQL semble trier par la clé primaire par défaut. Cependant, à tout moment où vous avez besoin de garantie que les lignes seront commandées d'une certaine manière, vous devriez ajouter de la commande par.
Seulement si la clé principale est également la clé de clustering - laquelle est par défaut, mais ne doit pas nécessairement être .......
Une table par défaut n'est pas «cluster», c'est-à-dire organisé par PK. Vous avez la possibilité de la spécifier comme tel. Donc, la valeur par défaut est "tas" (sans ordre particulier), et l'option que vous recherchez est "clustered" (SQL Server, dans Oracle it appelé iot).
L'affiche antérieure est correcte, SQL (et la base théorique de celle-ci) définit spécifiquement une sélection de sélectif / tuple non ordonné.
SQL essaie généralement de rester dans le domaine logique et de ne pas faire d'hypothèses sur les organisations / emplacements physiques, etc. des données. L'option en clustere nous permet de le faire pour des situations de vie réelle pratiques.
Presque chaque fois qu'il triera par l'identité des tables. Il trie par l'indice en cluster comme et peut ne pas toujours être trié par l'identité, mais je ne l'ai jamais vu non trié par l'ID d'identité lors de la sélection *. Quelle est la raison de ne pas spécifier une commande par? Je ne vois pas pourquoi cela provoque une différence de performance.
Sans ordre explicite de, il n'y a pas d'ordre de tri par défaut. Une question très commune. En tant que tel, il y a une réponse en conserve:
Sans commande par, il n'y a pas d'ordre de tri par défaut.
Pouvez-vous élaborer pourquoi "la différence de performance est significative."?
Les données sont des séries chronologiques et les requêtes tirent des mois de retour de données. Sans la commande par la procédure stockée est capable de commencer à renvoyer des lignes en quelques secondes. Avec la commande par elle dépend d'une minute avant la première rangée.
Vous pouvez essayer l'option (Fast 1) MSDN.MicRosoft.com/en-us /Library/ms181714.aspx
Le lien ne fonctionne plus
Vous devez appliquer la commande par pour garantir une commande. Si vous remarquez une différence de performance que ce n'est probablement que vos données n'ont pas été triée sans la commande par en place - sinon SQL-Server doit se comporter mal car il ne réalise pas que les données sont déjà triées. Ajout de la commande par sur les données déjà triées ne doit pas entraîner une pénalité de performance car les SGBD devraient être suffisamment intelligents pour réaliser l'ordre des données.
Dupliqué possible de est 'Sélectionner' toujours commander par la clé primaire?