Discussion :

[Phenol]

Bonjour,

Un client de la Web Agency où je bosse se sert d'un CSV (en provenance de Sage) pour importer ses produits, leurs caractéristiques ainsi que d'autres informations liées à ceux-ci.

Bref, plutôt qu'effectuer une requête SQL de type INSERT par produits/caractéristiques, nous avons décidé de créer un fichier .sql contenant toutes les requêtes (1 par ligne) et de l'importer par la suite via un script Shell.

Ce .sql comporte donc environ 15000 lignes et met actuellement 20 minutes à être importé.

Ma question est la suivante : est-ce une durée normale ? Si non, comment réduire cette durée, quels paramètres optimiser sur le serveur dédié (http://www.ovh.com/fr/produits/superplan_best_of.xml) ?

Informations :
- les tables concernées sont en InnoDB
- un import local (WAMP) du .sql met environ 1 minute à être effectué (via PHPMyAdmin > Importer)

Je suis à votre disposition pour toute information qui pourrait vous aider à répondre à ma question.

Merci par avance.

[patic]

Bonjour,
Avez vous essayé de tester le lancement du script directement en local, c'est à dire après avoir uploadé le fichier (par ftp par exemple) sur le serveur puis via le shell à distance ?
Cela vous indiquerait déjà d'où vient le problème, la connexion ou bien le serveur ...

[Phenol]

Tout d'abord merci pour votre réponse.

Pour répondre à votre question : Oui, le script Shell télécharge le .sql avant de l'exécuter en local.

[patic]

On s'est mal compris, pour trouver l'origine du problème, il faudrait tester manuellement, sans utiliser le script automatique déjà fait.
Vous téléchargez manuellement le fichier .sql sur le serveur puis vous ouvrez un shell à distance, lancez une session mysql et exécutez le script. Si ce dernier point met toujours 20 minutes, vous aurez déjà identifié la source du problème. En gros il faut découper les tâches du script une à une, jusqu'à tomber sur le problème.

[Phenol]

Le script Shell ne fait qu'un "mysql .......... < data.sql".

J'ai testé directement la commande dans le Shell avec le même résultat.

J'espère répondre concrètement à votre question et l'avoir bien comprise.

Merci encore.

[Nudger]

Bonjour,

15000 en 20 minutes, ça fait 12,5 par seconde.
Suivant le contexte c'est peut-être pas si mal que ça.

- Combien de lignes contient la table ?
- Combien de colonnes contient la table ?
- Combien d'index y a-t-il sur cette table ?
- Y a-t-il des triggers sur la table ?
- Le script est-il exécuté sur le serveur qui héberge la base MySQL ?

[CinePhil]

Un client de la Web Agency où je bosse se sert d'un CSV (en provenance de Sage) pour importer ses produits, leurs caractéristiques ainsi que d'autres informations liées à ceux-ci.

Plutôt que de faire 15 000 INSERT, tu as essayé LOAD DATA INFILE ?
Et s'il faut ensuite répartir les données dans plusieurs tables, tu charges le CSV dans une table temporaire avec LOAD DATA INFILE puis avec les requêtes adéquates, tu répartis les données dans les bonnes tables.
C'est peut-être plus long à préparer mais si c'est une opération répétitive, ce sera sûrement plus rapide à terme.

[qi130]

Les tables sont en InnoDB...

Il y a donc des FK et le contrôle de leur respect ce qui n'est pas gratuit non plus.

Est il envisageable d'effectuer un commit de temps en temps afin d'alléger la journalisation ?

[kedare]

Tu fais bien tout dans une seule transaction ?
Si c'est pas le cas il y a un commit a chaque insert donc c'est normal que ca soit lent...

[slefevre01]

Salut,
peux-tu transmettre ton my.cnf ?

Comme t'es sur un dédié, tu peux exécuter mysqltuner qui te fournira qq pistes d'optimisation. http://blog.mysqltuner.com/download/

Sébastien

[patic]

Bonjour,
A mon avis, si le test met 1 minute sur une simple machine tournant sous windows comparé à 20 minutes sur un serveur sous linux je suppose que c'est que vous n'avez pas la même configuration entre les deux machines, sous windows mysql est bien plus lent même avec la 5.5. Voir les contraintes comme les clés étrangères des tables en innodb, les triggers, les index aussi.
Avez vous essayé avec un ETL du type de Pentaho Kettle (à condition que vous ayez un accès distant à la base), c'est ultra simple dans des cas d'import sans modification comme ici ?
Sinon, découpez votre script .sql pour voir quelle partie est la source d'étranglement.