[Question] INSERT INTO

Bonjour,

J'aurai une petite question (remarque on est là pour ça :mouarf:)

Qu'est ce qui est le plus rapide donc mieux ?

Utiliser INSERT INTO avec plusieurs UNION ?
ou bien
Utiliser plusieurs INSERT INTO en parallèle ?

Ceci bien sûr sur la même table.

Merci pour vos différentes réponses.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

INSERT INTO MaTablePrincipale ( Champs1, Champs2, Champs3, ... ... ) SELECT Champs1, Champs2, Champs3, ... ... FROM MaTable1 UNION SELECT Champs1, Champs2, Champs3, ... ... FROM MaTable2 UNION SELECT Champs1, Champs2, Champs3, ... ... FROM MaTable3 UNION ... ... ...

---

Ou

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

INSERT INTO MaTablePrincipale ( Champs1, Champs2, Champs3, ... ... ) SELECT Champs1, Champs2, Champs3, ... ... FROM MaTable1

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

INSERT INTO MaTablePrincipale ( Champs1, Champs2, Champs3, ... ... ) SELECT Champs1, Champs2, Champs3, ... ... FROM MaTable2

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

INSERT INTO MaTablePrincipale ( Champs1, Champs2, Champs3, ... ... ) SELECT Champs1, Champs2, Champs3, ... ... FROM MaTable3

---

Ceci autant de fois en parallèle que nécessaire.

Il y a deux syntaxes pour l'insertion de données :

Code:

---

1 2 3 4 5 6 7

INSERT INTO la_table (les_colonnes) VALUES (les_valeurs_1), (les_valeurs_2), (les_valeurs_n)   INSERT INTO la_table (les_colonnes) SELECT des_colonnes FROM une_autre_table WHERE conition

---

Si tu n'as qu'une ou quelques valeurs saisies par l'utilisateur, utilise la première syntaxe. Si tu as beaucoup de valeurs provenant d'autres tables, utilise la seconde.

Justement c'est pour injecter les donner de différentes tables dans une même TablePrincipale.
D'où l'utilisation que je faisais avec les UNION.
Mais comme c'est un script qui est lancé très régulièrement j'ai donc besoin que l'injection se fasse très rapidement d'où ma question.
Utiliser plusieurs script en parallèle qui injectent les données de différentes tables dans une même table ou bien utiliser un seul script utilisant UNION.
De plus, UNION va injecter dans la TablePrincipale toutes les tables les unes à la suite des autres alors que le fait d'utiliser plusieurs scripts en paralèle va les injecter un peu comme les données arrivent.
Tout est une question de choix afin que l'injection des différentes tables via script se fasse très rapidement.

Tu ne peux pas faire des inserts "en parallèle". Une requête sera plus rapide à exécuter que plusieurs et une requête sera plus rapide qu'une union de requêtes, si tu as la possibilité d'éviter l'UNION.

Citation:

---

De plus, UNION va injecter dans la TablePrincipale toutes les tables les unes à la suite des autres alors que le fait d'utiliser plusieurs scripts en paralèle va les injecter un peu comme les données arrivent.

---

Et alors ?

Une table SQL est un ensemble. Il ne faut pas y chercher un ordre a priori. C'est lors des requêtes qu'on choisit l'ordre dans lequel on va récupérer les données.

Et si tu décrivais plus concrêtement ton besoin ?

Citation:

---

Une table SQL est un ensemble. Il ne faut pas y chercher un ordre a priori. C'est lors des requêtes qu'on choisit l'ordre dans lequel on va récupérer les données.

---

Nous sommes bien d'accord là-dessus.

Citation:

---

Et si tu décrivais plus concrêtement ton besoin ?

---

C'est justement ce que j'essaie d'expliquer.

Actuellement, j'ai un script batch qui injecte les données de différentes tables vers MaTablePrincipale, ceci toutes les 30min
La requête d'injection utilise UNION et donc les données dans MaTablePrincipale se retrouvent être les données des tables injectées les unes après les autres et ceci prend donc un certain tps.
En gros l'UNION va injecter les données de la Table1 ensuite la Table2 puis la Table3, etc...
On remarque donc que les données de la Table3 ne seront injectées que lorsque les données de la Table1 et Table2 seront, elles, complètement injectées. Ceci prend donc du tps.
Le but de ma question était de savoir si le fait de lancer plusieurs script en parallèle va permettre de gagner du tps puisque du coup le CPU et la MaTablePrincipale se retrouverait pas mal chargée.
En gros au lieu d'avoir les données des différentes tables les unes derrières les autres, plutôt les avoir toutes mélangées (celà n'a aucune importance comme tu le signales)

Lancer en même tps les 3 requêtes INSERT INTO MaTablePrincipale .... ou bien une seule et unique requête INSERT INTO ... UNION... UNION.... UNION...
Qu'est ce qui prendrait le moins de tps ?
Je ne vois pas comment l'expliquer autrement là. :-(

Citation:

---

j'ai un script batch qui injecte les données de différentes tables vers MaTablePrincipale

---

On reste dans l'abstrait !
Quel domaine est concerné ? Des voitures, des recettes de cuisine, des enquêtes d'opinion, des paniers de vente en ligne, des vols de compagnies aériennes, des productions de pièces industrielles... ?

Alors restons dans l'abstraction et essayons de couper ce brouillard...

Une requête UNION, c'est une requête SELECT... UNION SELECT....
Donc ton insertion doit être de ce type :

Code:

---

1 2 3 4 5 6

INSERT INTO laTablePrincipale (les_colonnes_à_alimenter) SELECT des_colonnes FROM une_table UNION SELECT d_autres_colonnes FROM une_autre_table

---

Le SGBD va d'abord exécuter la requête SELECT UNION. Au passage, il va éliminer les éventuels doublons sinon il faut utiliser UNION ALL.
Puis il va insérer l'ensemble résultat de la requête UNION dans la table principale. Alors va s'opérer la restructuration des index éventuels de la table principale, en une seule passe.

Si tu fais une succession de requêtes :

Code:

---

1 2 3 4 5 6 7

INSERT INTO laTablePrincipale (les_colonnes_à_alimenter) SELECT des_colonnes FROM une_table;   INSERT INTO laTablePrincipale (les_colonnes_à_alimenter) SELECT d_autres_colonnes FROM une_autre_table;

---

Il va d'abord effectivement insérer les données de la première requête, remanier les index, puis insérer les données de la deuxième requête et remanier de nouveau les index. Logiquement, ça devrait prendre plus de temps. Surtout qu'entre les deux requêtes, si elles sont lancées successivement par un programme externe, il y a aura deux réponses du SGBD au programme pour dire que ça s'est bien déroulé ou que ça a planté, donc un temps de latence entre les deux requêtes.

Mais au delà de ça, je me demande pourquoi tu as besoin de faire ça, surtout toutes les 30 minutes ?
C'est de la consolidation de données sur un serveur central par rapport à des serveurs répartis ? Il existe des outils de réplication dans tous les bons SGBD. C'est parfaois pas de la tarte à mettre en oeuvre mais c'est sûrement plus optimisé que de le faire à la main.

Bon, je suis toujours dans le brouillard quant à ton besoin !

C'est une base interne (certe loin pas parfaite) mais qui remonte toutes les infos nécessaire.
Celle-ci permet de gérer automatiquement plusieurs serveurs distants.
En gros elle sert de consolidation de plusieurs BDD distantes. Mais, car il y a un mais, ce ne sont pas des BDD MySQL, ce sont des bases propriétaires qui sont exportées via des scripts d'où l'utilisation des scripts pour réinjection dans ma BDD MySQL
Après que ce soit pour des voitures, des clients, des photos, ou tout autres c'est le même principe.
Comme tu vois, il m'est totalement impossible d'utiliser la réplication de BDD.
Les données sont récupérées toutes les 30min en journée et nuit mais aux heures de pointes celles-ci sont récupérées toutes les 15min.
La récupérations et l'injection des données dans les différentes tables "filles" se faisant dès récupération des BDD distantes et ceci fonctionne très bien.
Le pb est la consolidation des différentes Tables "Filles" pour les mettre dans la Table Principale.

Est-ce un peu plus clair ou es-tu toujours dans le brouillard total ?

Juste pour compléter, les exports des différentes BDD sont des fichier CSV que je traite afin de les injecter dans des tables MySQL.
La BDD MySQL intègre plusieurs Tables par serveurs distants en fonction des données à y intégrer.
Ensuite il y a plusieurs tables qui consolident les différentes tables serveurs (toujours en fonction de leurs données)

Tout ceci fonctionne très bien mais c'était surtout au niveau des performances que je voulais travailler, afin que les données soient réinjecter le plus rapidement possibles.

Oui j'y vois plus clair. Ce que tu appelles "tables filles" sont en fait des tables temporaires d'importation de données externes.

Alors ne te pose pas de question et utilise une requête INSERT SELECT UNION SELECT.

OK Donc je reste comme je suis.
Actuellement j'ai :
- plusieurs scripts qui exportent les différentes BDD en CSV
- plusieurs autres scripts qui injectent en parallèle dans les différentes tables filles (temporaires) pour un premier traitement d'épuration des données.
- Un script qui réinjecte les données des différentes tables filles (temporaires) vers les tables principales (pour utilisation de la BDD) Le tout via des INSERT INTO SELECT UNION comme l'indique mes précédents messages.
Il n'est pas possible d'accélérer les injections alors ?! :-( en fait le serveur passe plus de tps sur le script de réinjection des données dans les tables principales que dans l'export et import dans les tables temporaires :-(

Quel est le volume de données traité par la requête d'insertion ?
Quel est le volume de la table principale ?
Quelles sont les structures des tables ?
Sont-elles indexées ?

Comme l'a dit cinéphil ,

Si tu n'as pas a t'occuper des doublons
- puisque tu envisageais trois requetes qui donc ne s'occuppent pas des doublons -
il sera moins couteux d'utiliser union all puisqu'il n'y aura pas de tri a faire,
tri d'autant plus couteux que le volume (nombre/taille de ligne) est important.

toutes les tables sont indexées.
De plus, ce qui prend du tps c'est l'injection des différentes tables filles (temporaires) dans la table principale
Les différents scripts d'imports dans les tables filles sont lancés en parallèle ce qui fait que toutes les tables filles sont renseignées en même tps au lieu que ce soit les unes après les autres.
Le script actuellement mis en place qui injecte les données de toutes les tables temporaires dans la table principale utilise UNION
Le but de ma question était de savoir si le fait de créer différents scripts pour injecter dans la tables principale (sur le même principe que l'injection dans les tables temporaires) étaient plus rapides. Les scripts étant lancés en parallèle. Donc Table1 + Table2 + Table3 +.... injectent les données en même tps dans la TablePrincipale
Sinon les tables filles ne sont pas bien grosses, elles tournent entre 1000 et 800000 lignes en fonction des tables.

Citation:

---

Le script actuellement mis en place qui injecte les données de toutes les tables temporaires dans la table principale utilise UNION

---

Tu parles d'une procédure SQL ou d'un programme externe qui génère un wagon de requêtes INSERT ?

ce sont des script de type "fichier.sql" lancer dans des batch à l'aide de la commande suivante :

Code:

---

1 2	D:\xampp\mysql\bin\mysql.exe -B --host=localhost --user=USER --password=PWD --database=db_MaBDD < E:\CheminFichiers\FichiersSQL\Global\InjectionTablesGlobales.sql

---

Dans le fichier SQL, se trouve les différentes requêtes avec UNION