Avec les bases de données les problèmes de lenteur peuvent venir d'un très grand nombre de causes. Question taille de la base, le nombre d'octets ne signifie pas grand chose, ça va plutôt être le nombre d'enregistrements qui va être déterminant. Quelques pistes :
Il faut bien séparer la lecture et l'écriture (qui sont de nature totalement différente pour les BDD) et savoir laquelle est lente. Une optimisation de la lecture a tendance à dégrader l'écriture et vice versa.
Souvent, il s'agit de quelques requêtes en lecture qui ralentissent tout. Ça peut se guérir par l'ajout d'indexes bien placés ou la réécriture des requêtes.
Inversement, si c'est l'écriture qui est lente, ça peut être dû à un excès d'indexes (il faut écrire dans la table et dans chacun des indexes).
S'il y a déjà beaucoup d'indexes, comme il y a beaucoup d'écriture, il peut y avoir un problème de déséquilibre des indexes. Pour faire simple, c'est un peu comme la fragmentation des disques. Il existe des opération rééquilibrant les indexes (la plus brutale, supprimer l'index et le recréer).
Il faut aussi vérifier que c'est bien programmé. Si le programme rapatrie toute la base à chaque requête, c'est le réseau qui doit pécher.
J'ai souvent entendu dire que MySQL était bon en lecture mais pas en écriture. C'est à vérifier, mais pas facile de tester une autre base comme ça (en fait j'ai travaillé longtemps avec Oracle mais chaque base est spécifique).
Autre chose, il est souvent bon de répartir les données accédées simultanément sur plusieurs disques. Par exemple, la table sur un disque et son index sur un autre. Ainsi on gagne beaucoup en temps d'aller retour table-index.
Peut être que MySQL possède des outils de monitoring qui peuvent te renseigner sur ce sur quoi elle dépense son temps.
C'était quelques pistes mais c'est quasiment impossible de diagnostiquer un problème de performance sans une quantité monstrueuse de données.
# Diagnostic difficile
Posté par pyrollo (site web personnel) . En réponse au journal Performance MYSQL. Évalué à 5.
Il faut bien séparer la lecture et l'écriture (qui sont de nature totalement différente pour les BDD) et savoir laquelle est lente. Une optimisation de la lecture a tendance à dégrader l'écriture et vice versa.
Souvent, il s'agit de quelques requêtes en lecture qui ralentissent tout. Ça peut se guérir par l'ajout d'indexes bien placés ou la réécriture des requêtes.
Inversement, si c'est l'écriture qui est lente, ça peut être dû à un excès d'indexes (il faut écrire dans la table et dans chacun des indexes).
S'il y a déjà beaucoup d'indexes, comme il y a beaucoup d'écriture, il peut y avoir un problème de déséquilibre des indexes. Pour faire simple, c'est un peu comme la fragmentation des disques. Il existe des opération rééquilibrant les indexes (la plus brutale, supprimer l'index et le recréer).
Il faut aussi vérifier que c'est bien programmé. Si le programme rapatrie toute la base à chaque requête, c'est le réseau qui doit pécher.
J'ai souvent entendu dire que MySQL était bon en lecture mais pas en écriture. C'est à vérifier, mais pas facile de tester une autre base comme ça (en fait j'ai travaillé longtemps avec Oracle mais chaque base est spécifique).
Autre chose, il est souvent bon de répartir les données accédées simultanément sur plusieurs disques. Par exemple, la table sur un disque et son index sur un autre. Ainsi on gagne beaucoup en temps d'aller retour table-index.
Peut être que MySQL possède des outils de monitoring qui peuvent te renseigner sur ce sur quoi elle dépense son temps.
C'était quelques pistes mais c'est quasiment impossible de diagnostiquer un problème de performance sans une quantité monstrueuse de données.