Discussion :

[izioto]

Bonjour,

J'aurai souhaité vos avis sur ma problématique.

J'ai une base de données Mysql 4.0 qui contient une table CLIENT (env. 800.000 lignes) de type innodb.

Chaque jour, je reçois un fichier descrivant des changements de contrat client que je dois integrer pour tenir ma bdd à jour.
Ce fichier de changements fait env. 100.000 lignes.

Si le client est dans ma base, 1 changement de contrat entraine deux requêtes au niveau de ma bdd :
- un update (mise a jour de contrat) ou un delete (resiliation),
- un insert (log de l'enregistrement du changement de contrat).

Par suite, et dans le cas ou les 100.000 lignes correspondraient au pire à des changements de contrat impactant 100.000 clients réellement dans ma
base (ce qui n'est pas forcement le cas), j'aurai :
- 100.000 select à faire pour vérifier que le client est dans ma base,
- le cas échéant, 200.000 requêtes (update ou delete + insert) à lancer sur le serveur MYSQL.


Par suite, plutot que de parcourrir le fichier avec un batch, de faire un select pour voir si le client existe dans ma base et ensuite faire l'opération
correspondante (= select + update ou delete + insert) si nécessaire, j'ai l'idée de créer un fichier contenant la totalité des commandes SQL (indépendamment du fait de savoir si le client existe bien chez moi), pour ensuite l'executer via "mysql .... < contrat.sql"

Pensez-vous que ce soit une bonne solution ?
Le fait de lancer un update sur une table qui retournerait "0 row(s) affected" est-il consomateur, est-il plus consomateur qu'un select ?

Merci de vos réponses !!
izioto

[izioto]

Bonsoir,

Mon post n'ayant pas l'air de mobiliser les foules je vais poser la question autrement !!

Imaginons que j'ai 100 select à faire pour conditionner la réalisation de 20 update. En tout cela fait 120 requêtes passées sur le serveur.

Est-il déconnant dans ce cas, de lancer directement 100 update en ce disant que 20 vont modifier la bdd et 80 retourneront "0 row(s) affected" !!

Lancer un update est-il plus consomateur qu'un select ?
Quels sont également les impacts en terme d'accès à la bdd par d'autre process (lock ??)

Maaaarci

[jeca]

Bonjour,

Tu peux regarder de ce côté :
http://dev.mysql.com/doc/refman/5.0/fr/replace.html

[papa6]

Salut,
vois le conseil de Jeca sur les Replace

Tu peux aussi peut-être faire un update avec jointure multitable (et te rapprocher d'un sélect) : ainsi seules les lignes retournées par le sélect seront mises à jour.
http://dev.mysql.com/doc/refman/5.0/fr/update.html (tout à la fin de l'article)

Quant à l'insert ... select ... c'est encore plus facile

[Sivrît]

Lancer un update est-il plus consomateur qu'un select ?
Quels sont également les impacts en terme d'accès à la bdd par d'autre process (lock ??)

Je ne suis pas tout à fait certain mais l'update ne doit pas être vraiment plus couteux s'il ne modifie rien. Par contre les verrous sont peut-être à surveiller surtout si la BDD est très utilisée pendant ce temps car même si la requête ne change rien InnoDB peut poser des verrous le temps de son exécution.

Sur un update InnoDb pose des verrous sur toutes les lignes examinées, même si elles ne sont pas au final modifiées. Si la recherche passe par un indexe très sélectif presque rien n'est verrouillé. Par contre si aucun indexe n'est utilisé (ou s'il est trop peu sélectif) on se retrouve à verrouiller toute la table.

A première vue ici les enregistrements concernés sont bien identifiés donc ça devrait aller...

...cela dit je suis myope