Quelle est la différence entre l'utilisation
SELECT ... INTO MyTable FROM...
et
INSERT INTO MyTable (...)
SELECT ... FROM ....
?
De BOL [ INSERT , SELECT ... INTO ], je sais que l'utilisation de SELECT ... INTO créera la table d'insertion sur le groupe de fichiers par défaut s'il n'existe pas déjà, et que la journalisation de cette instruction dépend de la récupération modèle de la base de données.
- Quelle déclaration est préférable?
- Y a-t-il d'autres implications sur les performances?
- Quel est un bon cas d'utilisation de SELECT ... INTO sur INSERT INTO ...?
Edit: J'ai déjà déclaré que je sais que ce SELECT INTO ... crée une table là où elle n'existe pas. Ce que je veux savoir, c'est que SQL inclut cette instruction pour une raison, qu'est-ce que c'est? Est-ce qu'il fait quelque chose de différent dans les coulisses pour insérer des lignes, ou est-ce juste du sucre syntaxique au-dessus d'un CREATE TABLE
et INSERT INTO
.
sql-server
tsql
sql-server-2008
jowenece
la source
la source
INSERT INTO
a deux mots clés (select & into) à l'avant qui permettent au monde de savoir qu'il ne s'agit pas d'une instruction SQL ordinaire, alors qu'elleSELECT ... INTO
commence, au moins, à ressembler à une instruction SQL ordinaire. Une petite raison de privilégier le premier.Réponses:
Ils font des choses différentes. À utiliser
INSERT
lorsque la table existe. À utiliserSELECT INTO
quand ce n'est pas le cas.Oui.
INSERT
sans indication de table est normalement consigné.SELECT INTO
est minimalement consigné en supposant que les indicateurs de trace appropriés sont définis.D'après mon expérience, il
SELECT INTO
est le plus couramment utilisé avec des ensembles de données intermédiaires, tels que des#temp
tables, ou pour copier une table entière comme pour une sauvegarde.INSERT INTO
est utilisé lorsque vous insérez dans une table existante avec une structure connue.ÉDITER
Pour répondre à votre modification, ils font des choses différentes. Si vous créez un tableau et que vous souhaitez définir la structure, utilisez
CREATE TABLE
etINSERT
. Exemple de problème pouvant être créé: vous avez une petite table avec un champ varchar. La plus grande chaîne de votre table est désormais de 12 octets. Votre ensemble de données réel nécessitera jusqu'à 200 octets. Si vous faites àSELECT INTO
partir de votre petite table pour en créer une nouvelle, la dernièreINSERT
échouera avec une erreur de troncature car vos champs sont trop petits.la source
CREATE TABLE
et ensuiteINSERT INTO
, il est plus facile de tester l'SELECT
instruction par elle-même, sans exécuter l'insertion.SELECT INTO
pour créer une table temporaire ou pour faire une sauvegarde rapide d'une table existante avec laquelle je vais faire un singe.CREATE
déclaration cependant.Quelle déclaration est préférable? Cela dépend de ce que vous faites.
Y a-t-il d'autres implications sur les performances? Si la table est une table permanente, vous pouvez créer des index au moment de la création de la table, ce qui a des implications négatives et positives sur les performances. Select into ne recrée pas les index qui existent sur les tables actuelles et, par conséquent, l'utilisation ultérieure de la table peut être plus lente que nécessaire.
Quel est un bon cas d'utilisation de SELECT ... INTO sur INSERT INTO ...? Sélectionner dans est utilisé si vous ne connaissez pas la structure du tableau à l'avance. Il est plus rapide d'écrire que de créer une table et une instruction d'insertion, il est donc parfois utilisé pour accélérer le développement. Il est souvent plus rapide à utiliser lorsque vous créez une table temporaire rapide pour tester des éléments ou une table de sauvegarde d'une requête spécifique (peut-être des enregistrements que vous allez supprimer). Il devrait être rare de le voir utilisé dans du code de production qui s'exécutera plusieurs fois (sauf pour les tables temporaires) car il échouera si la table existait déjà.
Il est parfois utilisé de manière inappropriée par des personnes qui ne savent pas ce qu'elles font. Et ils peuvent causer des ravages dans la base de données. Je pense fortement qu'il est inapproprié d'utiliser SELECT INTO pour autre chose qu'une table jetable (une sauvegarde temporaire, une table temporaire qui disparaîtra à la fin du processus stocké, etc.). Les tables permanentes nécessitent une réflexion approfondie quant à leur conception et SELECT INTO permet d'éviter de penser à quelque chose d'aussi basique que les colonnes et les types de données.
En général, je préfère l'utilisation de l'instruction create table et insert - vous avez plus de contrôles et c'est mieux pour les processus répétables. En outre, si la table est une table permanente, elle doit être créée à partir d'un script de création de table distinct (celui qui est dans le contrôle de code source) car la création d'objets permanents ne devrait pas, en général, dans le code être des insertions / suppressions / mises à jour ou des sélections à partir d'un table. Les modifications d'objets doivent être traitées séparément des modifications de données, car les objets ont des implications au-delà des besoins d'une insertion / mise à jour / sélection / suppression spécifique. Vous devez considérer les meilleurs types de données, penser aux contraintes FK, PK et autres contraintes, prendre en compte les exigences d'audit, penser à l'indexation, etc.
la source
La principale différence est que SELECT INTO MyTable créera une nouvelle table appelée MyTable avec les résultats, tandis que INSERT INTO requiert que MyTable existe déjà.
Vous n'utiliseriez SELECT INTO que dans le cas où la table n'existait pas et que vous souhaitiez la créer en fonction des résultats de votre requête. En tant que tels, ces deux déclarations ne sont vraiment pas comparables. Ils font des choses très différentes.
En général, SELECT INTO est utilisé plus souvent pour des tâches ponctuelles, tandis que INSERT INTO est utilisé régulièrement pour ajouter des lignes aux tables.
EDIT:
Bien que vous puissiez utiliser CREATE TABLE et INSERT INTO pour accomplir ce que SELECT INTO fait, avec SELECT INTO vous n'avez pas besoin de connaître la définition de la table au préalable. SELECT INTO est probablement inclus dans SQL car il facilite beaucoup les tâches telles que la création de rapports ad hoc ou la copie de tables.
la source
Chaque instruction a un cas d'utilisation distinct. Ils ne sont pas interchangeables.
SELECT...INTO MyTable...
crée un nouveauMyTable
là où il n'en existait pas auparavant.INSERT INTO MyTable...SELECT...
est utilisé lorsqu'ilMyTable
existe déjà.la source
En fait SELECT ... INTO crée non seulement la table, mais échouera si elle existe déjà, donc fondamentalement, la seule fois où vous l'utiliserez est lorsque la table dans laquelle vous insérez n'existe pas.
En ce qui concerne votre EDIT:
Personnellement, j'utilise principalement SELECT ... INTO lorsque je crée une table temporaire. C'est pour moi la principale utilisation. Cependant, je l'utilise également lors de la création de nouvelles tables avec de nombreuses colonnes avec des structures similaires à celles d'autres tables, puis je les modifie afin de gagner du temps.
la source
SELECT INTO est généralement utilisé pour générer des tables temporaires ou pour copier une autre table (données et / ou structure).
Dans le code au jour le jour, vous utilisez INSERT car vos tables doivent déjà exister pour être lues, UPDATEd, DELETEd, JOINed etc. Remarque: le mot clé INTO est facultatif avec INSERT
Autrement dit, les applications ne créeront et ne supprimeront normalement pas de tables dans le cadre d'opérations normales, sauf s'il s'agit d'une table temporaire pour une utilisation limitée et spécifique.
Une table créée par SELECT INTO n'aura pas de clés, d'index ou de contraintes contrairement à une table réelle, persistante et déjà existante
Les 2 ne sont pas directement comparables car ils n'ont presque aucun chevauchement d'utilisation
la source
Je veux seulement aborder le deuxième point de la question qui a trait à la performance, car aucune autre instance ne l'a couvert. Select Into est beaucoup plus rapide que l'insertion dans, lorsqu'il s'agit de tables avec de grands ensembles de données. Je préfère choisir dans quand je dois lire un très grand tableau. insérer dans pour une table avec 10 millions de lignes peut prendre des heures tandis que select into le fera en quelques minutes, et quant à la perte d'index sur une nouvelle table, vous pouvez recréer les index par requête et pouvez encore gagner beaucoup plus de temps par rapport à insérer dans.
la source
insert into #temp with(tablock) select * from ..
est à peu près la même que celle deselect * into #temp from ...
Sélectionnez dans crée une nouvelle table pour vous à ce moment-là, puis insérez-y des enregistrements à partir de la table source. La table nouvellement créée a la même structure que la table source.Si vous essayez d'utiliser select into pour une table existante, cela produira une erreur, car il essaiera de créer une nouvelle table avec le même nom. Insérer dans nécessite que la table existe dans votre base de données avant d'y insérer des lignes.
la source
La simple différence entre sélectionner dans et insérer dans est: -> Sélectionner dans n'a pas besoin de table existante. Si vous voulez copier les données de la table A, il vous suffit de taper Select * INTO [tablename] from A. Ici, tablename peut être une table existante ou une nouvelle table sera créée qui a la même structure que la table A.
-> Insérer dans nécessite une table existante.INSERT INTO [nomtable] SELECT * FROM A ;. Ici, nom_table est une table existante.
Select Into est généralement plus populaire pour copier des données, en particulier les données de sauvegarde.
Vous pouvez utiliser selon vos besoins, c'est totalement le choix du développeur qui doit être utilisé dans son scénario.
En termes de performances, Insert INTO est rapide.
Références :
https://www.w3schools.com/sql/sql_insert_into_select.asp https://www.w3schools.com/sql/sql_select_into.asp
la source
Sélectionner dans pour les grands ensembles de données peut ne convenir qu'à un seul utilisateur utilisant une seule connexion à la base de données effectuant une tâche d'opération en bloc. Je ne recommande pas d'utiliser
car cela crée une grosse transaction et crée un verrou de schéma pour créer l'objet, empêchant les autres utilisateurs de créer un objet ou d'accéder aux objets système jusqu'à la fin de l'
SELECT INTO
opération.Comme preuve de concept, ouvrez 2 sessions, dans la première session essayez d'utiliser
et dans la deuxième section, essayez de
et vérifiez les verrous, le blocage et la durée de la deuxième session pour créer un objet de table temporaire. Ma recommandation est toujours une bonne pratique de créer et d'insérer une instruction et, si nécessaire, pour une journalisation minimale, utilisez l'indicateur de trace 610.
la source