Discussion :

[Christophe Charron]

Bonjour,
je fais quelques tests pour essayer de comprendre, pour essayer de choisir une méthode pertinente. A priori, je n'aurai jamais ce genre de volume, en une seule fois en production, mais j'aime bien comprendre !! Je pensais que la première syntaxe ci-après serait beaucoup plus rapide et il n'en est rien. Est-ce normal ? Il y a-t'il un paramétrage particulier à mettre en oeuvre ? La 3° requête n'est là que pour me rassurer sur le choix de la première ou de la seconde requete !!!

Bref, je suis preneur de vos remarques, car plus je découvre MySql et les posts dans ce forum, plus je me dis qu'il faut être fin au niveau des paramètrages et de la maintenance de la BD, alors si je peux être "intelligent" du départ, je pense que je gagnerai du temps.



Gestion des logs active

Insertion de 44617 enregistrements en un bloc : syntaxe :Insert into Tel_MP_02 (telnum)

VALUES(124373233),(127600677),(127600677) etc
dans la table qui en comptait 44617 : 2'2''13

Insertion de 44617 enregistrements en 44617 requêtes (Insert into Tel_monprospectv3 (telnum)

VALUES (826025006) avec début et fin transaction dans la table vide : 48'' 13



Insertion de 44617 enregistrements en 44617 requêtes (Insert into Tel_monprospectv3 (telnum)

VALUES (826025006) les unes à la suite des autres dans la table qui en comptait 44617 :

43'22'24

Et oui, KOLOSSAL

--
Cordialement
Christophe Charron

[ren0]

Tu es sous InnoDB n'est-ca pas ?

l'auto-commit est il activé ou non ?

tes tables de test ont-elles la même structure, les mêmes index, les mêmes valeurs par défaut ?

Y a t'il une intégrité référentielle à vérifier sur une de tes colonnes ?

quoi qu'il en soit, pour un chargement de gros volumes, si tu le peux préferes le LOAD DATA INFILE (chargement brut depuis un fichier) beaucoup plus performant...

[Christophe Charron]

Bonjour,
et merci de m'accorder un peu d'attention
Oui suis sous innodb, oui les tables sont strictements identiques, et comment savoir si l'auto-commit est activé ? Mais je le pense car lors d'un autre test, qui ne portait pas sur la rapidité, je pouvais consulter les données ajoutées au fûr et à mesure de leur insertion.
Non aucune de colonne n'est liée de quelque manière que ce soit à une autre
Et je suis bien d'accord pour les load data infile, sur des tables simples sans index ni intégrité référentielle. Justement, est-il possible de désactiver l'intégrité référetielle, pour une table, un utilisateur à un moment donné, le temps de faire ce load data infile encore plus rapide ?

--
Cordialement
Christophe Charron

[ren0]

Pour désactiver l'intégrité réferencielle, tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql> SET FOREIGN_KEY_CHECKS = 0

Pour tes index tu les DROP avant ton import et tu le recrée aprés.

Pour ce qui est de l'auto commit (qui selon moi plombe ton temps d'exec), tu peux voir si il est actif via :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql> show variables like "auto_commit"

retente tes tests en désactivant l'auto_commit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
mysql> SET AUTOCOMMIT=0;
 
START TRANSACTION;
Insert into Tel_MP_02 (telnum)
 
VALUES(124373233),(127600677),(127600677) etc
COMMIT;

temps ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
START TRANSACTION;
Insertion de 44617 enregistrements en 44617 requêtes (Insert into Tel_monprospectv3 (telnum)
 
VALUES (826025006) les unes à la suite des autres
COMMIT;

temps ?

Pour que le test soit cohérent procede à chaque fois dans des tables vides ou pleines, mais pas une vide et une pleine...

[Christophe Charron]

Pour désactiver l'intégrité réferencielle, tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql> SET FOREIGN_KEY_CHECKS = 0

Je ne gère pas d'intégrité référentielle, du moins sur cette table : est-il préférable de tout de même la désactiver ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql> show variables like "auto_commit"

Je dois pas être très doué, mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"show variables like "auto_commit"

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

show variables like "auto_commit%"

ou les variantes en majuscules ou sans l'underscore ne me renvoient rien !!!
De même

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

show global variables

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

show session variables

ne retournent rien qui ressemble à de l'autocommit !!

Mais bon, je débute en MySQL, comme tu peux le constater ...
C'est quoi ce binz ?

--
Cordialement
Christophe Charron

[ren0]

Non c'est moi qui t'ai dit une bétise,

J'ai regardé, et apparement impossible de checker la valeur du mode autocommit qui semble être actif par défaut.

Tu peux par contre avoir des stats sur InnoDB avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql> SHOW INNODB STATUS

En fait, ton besoin exactement, c'est quoi ? c'est d'optimiser ton import ? de monitorer ta base ? autre chose ?

[Christophe Charron]

En fait, ton besoin exactement, c'est quoi ? c'est d'optimiser ton import ? de monitorer ta base ? autre chose ?

En fait, c'est de savoir s'il est possible d'établir une règle pour choisir le meilleur type d'insert possible en production. Quand je constate que l'on peut avoir un plus que doublement du temps, mis en valeur par le volume, il est vrai, je me dis qu'il vaudrait mieux que je construise mes requêtes tout de suite de la bonne façon ( j'exclu d'emblée la 3° requête ).
Il est vrai que sur 100 insert, la différence sera imperceptible mais bon aujourdh'ui c'est 100, demain peut-être 1000.

[ren0]

Regarde les perfs, ok !
Mais essaye aussi d'adopter un regard fonctionnel sur tes inserts.

Tu es sous InnoDB, donc chaque insert non "commité" va te générer des lignes dans les rollbacks segments... => Accroissement du volume des RBS gérés par le SGBD => Baisse de perf global et risque d'éclatement de RBS ou de saturation de disque.
Dans ce cas extreme, les enregistrements non commités ne sont pas enregistrés en base => dommage !

Il est donc parfois nécessaire de procéder ligne à ligne pour assurer un maximum. Mais c'est trés gourmand en perf ! On préfere les commit partiel toutes les xxxx lignes...

Ce que tu peux faire pour finaliser tes tests, compare tes perfs avec un e table MyIsam.
Si la différence est trés significative, tu peux procéder en deux temps :
- faire une import dans ta table MyIsam
- faire un INSERT INTO ma_table_innoDB ... SELECT * FROM ma_table_MyIsam

Tu passe par une table d'intégration, qui te feras peut-être gagner du temps...