Problème de LOCK MySQL

Bonjour,

J'aimerai avoir quelques conseils pour optimiser les performances de ma base de données.

Voici déjà quelques statistiques sur les requêtes:
Total : 81 M
ø par heure : 145,07 k
ø par minute : 2,42 k
ø par seconde : 40,30


Je suis souvent confronté à des blocages de mes requêtes (lock) car j'ai sur mon site un robot qui crawl des pages en continu pour mettre à jour le contenu vu par les utilisateurs du site.
Donc la table principale du site est constamment assiégé de requête INSERT, SELECT, UPDATE etc...

Pour essayer de ménager la table, je joue beaucoup avec les HIGH/LOW PRIORITY, INSERT DELAYED etc... Mais ce n'est pas suffisant, je suis obliger de restreindre l'accès du site aux spider voir même aux utilisateurs lorsque le nombre de thread mysql dépasse un certain nombre.
Bref c'est vraiment du bidouillage et ce que j'aimerai c'est savoir si il n y aurai pas un moyen d'optimiser tous ça ?

Je suis sur un MySQL 4.1.22, je n'ai pas encore passé sur MySQL 5 ou 5.4, y a t'il eu des évolutions qui pourrait régler mon souci ?

Merci !

L'optimisation commence par le modèle de données. Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisation/
(bien que ces papiers soient écrit pour SQL Server ils sont valable quelque soit le SGBDR)
Votre base respecte-elle les 3 premières forme normale ? Si non, n'espérez jamais des performances !

A +

Merci, je vais lire les documents et vérifier que je n'est pas fait de boulette.

Citation:

---

Envoyé par SQLpro

Votre base respecte-elle les 3 premières forme normale ? Si non, n'espérez jamais des performances !

---

Ca m'étonne, la normalisation nuit aux performances plutôt qu'autre chose, non ?
Dans les Datawarehouses on évite de normaliser les tables car ca nuit aux performances.

Citation:

---

Envoyé par FFFFFF-000000

Ca m'étonne, la normalisation nuit aux performances plutôt qu'autre chose, non ?
Dans les Datawarehouses on évite de normaliser les tables car ca nuit aux performances.

---

Lisez l'article au lieu de dire des énormités pareilles ! A votre avis les bases de données relationnelles sont faites pour faire des relations ou des fichiers Cobol ?

Pour un data warehouse le problème n'est pas du tout le même car :
1) il n'y a pas de transaction puisqu'en principe il n'y a qu'un seul utilisateur qui met à jour
2) le nombre de mise à jour concurrentielle est très faibles par rapport au nombre de lectures puisqu'en principe il n'y a qu'un écrivain
3) cela répond à des besoins fonctionnels très différents de celui des applications de gestion.

Je doute que vous fassiez un site web marchand en utilisant une structure décisionnelle pour vendre vos produits !

A +

Citation:

---

Envoyé par SQLpro

Lisez l'article au lieu de dire des énormités pareilles !

---

OK je vais y jeter un coup d'oeil..

EDIT:

Mais je ne dis pas d'énormités...

La normalisation est efficace dans un contexte transactionnel intensif.

Pour le web, ce n'est pas toujours le cas.

Si vous avez l'esprit ouvert et un peu de temps :

http://highscalability.com/scaling-s...eed-and-profit

Citation:

---

Flickr both denormalizes and duplicates data. Horror!
Ebay is the most radical in moving almost all functionality out of the database and into the application.
Plenty of Fish also advocates denormalization as a key strategy.

---

Citation:

---

Envoyé par FFFFFF-000000

Si vous avez l'esprit ouvert et un peu de temps :

http://highscalability.com/scaling-s...eed-and-profit

---

Dans cet article on lit les habituelles imbécilités comme : "The problem is joins are relatively slow..."
C'est bien évidemment le contraire à condition de savoir utiliser les types de données judicieux et de savoir modéliser.

Pour ma part je modélise des bases de données considérables (genre ERP) dans lequel les volumes attendus se mesurent en To et mes tables font en moyenne moins de 8 colonnes et mes requêtes plus de 10 jointures avec des performances tout à fait normales (quelques ms pour la plupart).

Les seules dénormalisations parfois nécessaires sont effectuées non pas sur le modèle mais de manière interne au SGBDR à l'aide par exemples de vues indexées ou de partitionnement....

A +