Qui est plus rapide/meilleur ? Sélectionnez * ou sélectionnez Colonne1, Colonne3, colum2, etc.

Question

J'ai entendu dire qu' SELECT * est généralement une mauvaise pratique à utiliser lors de l'écriture des commandes SQL, car il est plus efficace d' SELECT colonnes que vous avez spécifiquement besoin.

Si j'ai besoin d' SELECT chaque colonne dans une table, dois-je utiliser SELECT * ou SELECT column1, colum2, column3, etc.

L'efficacité vraiment d'importance dans ce cas? Je pensais SELECT * serait plus optimale en interne si vous avez vraiment besoin de toutes les données, mais je dis cela sans réelle compréhension des bases de données.

Je suis curieux de savoir quelle est la meilleure pratique dans ce cas.

Mise à JOUR: j'ai sans doute faut préciser que la seule situation où j'aurais vraiment envie de faire un SELECT * , c'est quand je suis à la sélection des données dans une table où je sais que toutes les colonnes doivent toujours être récupéré, même lorsque de nouvelles colonnes sont ajoutées.

Compte tenu des réactions que j'ai vu toutefois, cela semble être une mauvaise idée et SELECT * ne doit jamais être utilisé pour beaucoup plus de raisons techniques que j'ai pensé.

Answer 1

L'une des raisons que la sélection des colonnes spécifiques est mieux, c'est qu'il augmente les chances que SQL Server peut accéder aux données à partir d'indices plutôt que d'interroger les données de la table. Voici un post que j'ai écrit à ce sujet: http://weblogs.asp.net/jgalloway/archive/2007/07/18/the-real-reason-select-queries-are-bad-index-coverage.aspx

C'est aussi moins fragile à changer, depuis n'importe quel code qui consomme les données seront obtenir la même structure de données, peu importe les changements que vous apportez à la table de schéma dans l'avenir.

Answer 2

Compte tenu de votre cahier des charges qui vous sont la sélection de toutes les colonnes, il y a peu de différence à ce moment. Réaliser, cependant, que les schémas de base de données changent. Si vous utilisez SELECT * vous allez obtenir toute les nouvelles colonnes sont ajoutées à la table, même si, en toute probabilité, votre code n'est pas prêt d'utiliser ou de présenter des nouvelles données. Cela signifie que vous êtes d'exposer votre système à des performances et des fonctionnalités des changements.

Vous pouvez être disposé à rejeter cela comme un moindre coût, mais se rendent compte que les colonnes que vous n'avez pas besoin d'doivent toujours être:

1. Lire à partir de la base de données
2. Envoyés à travers le réseau
3. Organisées dans votre processus
4. (pour ADO technologies de type) Enregistrés dans une table de données en mémoire
5. Ignorés et rejetés / garbage collector

L'élément n ° 1 a de nombreux coûts cachés, y compris l'élimination d'un certain potentiel index de couverture, causant de données chargement de la page (et le serveur cache raclée), encourir ligne / page / table des verrous qui pourrait en être autrement à éviter.

Bilan de ce contre, le potentiel d'économie de spécifier les colonnes contre une * , et le seul potentiel d'économies:

1. Programmeur n'a pas besoin de revoir le SQL pour ajouter des colonnes
2. Le réseau de transport de la SQL est plus petit, plus rapide
3. SQL Server query analyser / moment de la validation
4. SQL Server query cache de plan

Pour le point 1, la réalité est que vous allez à ajouter / modifier le code pour utiliser une nouvelle colonne, vous pouvez ajouter de toute façon, donc c'est un lavage.

Pour le point 2, la différence est rarement suffisante pour vous pousser dans un autre paquet de taille ou de nombre de paquets réseau. Si vous arrivez à un point où l'instruction SQL de temps de transmission est le principal problème, vous avez probablement besoin de réduire le taux de déclarations d'abord.

Pour le point 3, il n'y a PAS d'épargne que l'expansion de l' * a lieu de toute façon, ce qui signifie que la consultation de la table(s) schéma de toute façon. De façon réaliste, qui liste les colonnes seront facturés au même prix, car ils doivent être validés par rapport au schéma. En d'autres termes c'est un système complet de lavage.

Pour le point 4, lorsque vous spécifiez les colonnes spécifiques, votre plan de requête cache pourrait obtenir plus grand, mais seulement si vous êtes aux prises avec différents ensembles de colonnes (ce qui n'est pas ce que vous avez spécifiée). Dans ce cas, vous ne voulez entrées de cache différent parce que vous souhaitez que les différents plans au besoin.

Donc, tout cela se résume, en raison de la manière que vous avez spécifié à la question, à la question de la résilience face à d'éventuelles modifications du schéma. Si vous êtes à la gravure de ce schéma dans la mémoire ROM (ça arrive), puis un * est parfaitement acceptable.

Cependant, ma ligne de conduite générale est que vous devez sélectionner uniquement les colonnes dont vous avez besoin, ce qui signifie que parfois, il va ressembler à vous demandons à tous d'entre eux, mais les Administrateurs de bases de données et le schéma de l'évolution, certaines nouvelles colonnes peuvent apparaître qui pourrait grandement affecter la requête.

Mon conseil est que vous devez TOUJOURS SÉLECTIONNER des colonnes spécifiques. Rappelez-vous que vous le faites bien ce que vous faites, donc il suffit de prendre l'habitude de faire.

Si vous vous demandez pourquoi un schéma peut changer sans changer le code, penser en termes de journal d'audit efficace/les dates d'expiration et d'autres choses semblables qui sont ajoutés par les Administrateurs de bases de données par voie systémique pour des questions de conformité. Une autre source de sournoises des changements est denormalizations pour la performance ailleurs dans le système ou de champs définis par l'utilisateur.

Answer 3

Vous devez uniquement sélectionner les colonnes que vous avez besoin. Même si vous avez besoin de toutes les colonnes, c'est encore mieux à la liste des noms de colonnes, de sorte que le serveur sql n'ont pas de système de requête de table pour les colonnes.

Aussi, votre application peut se briser si quelqu'un ajoute des colonnes de la table. Votre programme sera colonnes, il n'attendez pas trop et il pourrait ne pas savoir comment les traiter.

En dehors de cela, si la table a une colonne binaire alors, la requête sera beaucoup plus lente et utiliser plus de ressources réseau.

Answer 4

Il y a quatre grandes raisons qui select * est une mauvaise chose:

1. La plus importante raison pratique, c'est qu'il oblige l'utilisateur, par magie, connaître l'ordre dans lequel les colonnes seront retournés. Il est préférable d'être explicite, ce qui vous protège également contre la table de change, qui enchaîne parfaitement dans...

2. Si un nom de colonne que vous utilisez, c'est mieux pour attraper dès le début (au moment de l'appel SQL) plutôt que lorsque vous essayez d'utiliser la colonne qui n'existe plus (ou n'a eu que son nom ait changé, etc.)

3. Liste les noms de colonne de votre code beaucoup plus auto-documenté, et donc probablement plus lisible.

4. Si vous effectuez un transfert sur un réseau (ou même si vous n'êtes pas), les colonnes que vous n'avez pas besoin, ce sont juste des déchets.