[gull] Optimisation Mysql

[Blaise Vogel]

Le Mercredi, 9 Mars 2005 18.57, Philippe Strauss a écrit :
...
> je n'ai jamais utilisé mysql pour des besoins pareils, mais arrive-tu
> a écrire une seule requête SQL pour tout ce bazar?
Oui. Si je cible bien mes requêtes avec des tables correctement indexées les 
temps de réponse sont excellents (moins de 0.1 secondes), pour par exemple 
une requête comprenant une dizaine de tables recherchant un champ par table 
(comme dit avant aucune table n'a moins de 100'000 lignes, au max 
10'000'000). Le "problème" actuel étant des stats annuels 01 - 02 -03 - 04 
pour beaucoup d'articles avec de la calculation (somme, compte,...). Je 
pourrais fragmenter en plusieurs requêtes, mais si j'évite le passage par la 
table temp. je gagne beaucoup de temps.

Pour la petite histoire, lors du choix de la base de données en 2001, j'avais 
fait des tests de charge sur plusieurs systèmes avec un HP netserver PIII 
monoproc + scsi 10'000 sans Raid. Passons les qualifications, au final il 
restait Postgre et Mysql. Mon coeur voulait Postgre (pour les 
fonctionnalités) mais les tests était clairement en faveur de Mysql (montée 
en charge, rapidité,ODBC), les fonctionnalités sont venues plus tard ou 
arriveront (par exemple procédure stockée). De plus j'ai pu éviter de coder 
la réplication de serveur (qui existait en version stable chez Mysql). Donc 
contrairement à beaucoup de troll, Mysql gére très bien les volumes moyens 
(pas tetsté des bases en TB !) et sa stabilité est exemplaire.

Il me reste à comprendre le message 'Copying to tmp table ...' Pas d'activité 
disque, pas de fichier temporaire, mystère. En contradiction avec la doc.

Blaise Vogel