Optimisation structure mysql

[Berberber]

D'un pas décidé, j'ai decidé de me pencher sur les requêtes mysql lentes de mon serveur.

Je me rends compte que de nombreuses tables mysql ne sont pas optimisées, et n'ont par exemple pas d'index.

Je suis en train de lire la doc mysql sur l'optimisation des requêtes, mais ce n'est pas vraiment évident. Alors je me permets de demander. (pas vraiment trouvé dans les 20 pages du forum mysql ici.

Imaginons que j'ai une grande table, ou je viens surtout chercher des données. Par rapport à une variable qui a un nom défini (ce nom étant completement irregulier et etant une chaine de caracteres.)

Cela servirait-il quelque chose à ajouter une variable index ? Je veux dire en ajoutant une simple colonne index, de laquelle je ne me soucierai plus, voulant toujours faire mes appels par rapport à la colonne avec le nom de la ligne.

(je vais commencer par cela, mon fichier de requetes "longues" est eternel).

Merci d'avance.

[Vincent]

Je ne comprends pas ton histoire de colonne supplémentaire pour un index.

un index n'est pas une colonne de ta table a proprement parler !

Cela dit, si tu as une table avec un champs texte et que tu accedes toujours par des critères sur ce champs a ta table, oui il faut rajouter un index.

L'index te permttra de diminuer le temps de réponse sur tes requetes de type 'select'

mais cela a l'inconvenient d'allonger les temps de réponse sur des requetes de type 'insert' ou 'update' etc... (celles qui modifient l'enregistrement). Car ces requetes après avoir modifié l'enregistrement, doivent mettre a jour l'index qui est lié.

Attention a ne pas mettre trop d'index... cela n'est pas non plus la solution pour s'imaginer optimiser les temps de réponse.

[Berberber]

Effectivement, je fait presque excusivement des SELECT, et peu de INSERT, mais je m'y perds quand même un peu : Primary, Index, Unique..... (quelles sont les differences ?)

Je vais travailler un peu mes connaissances là dessus. (si quelqu'un avait de bons liens, car la doc mysql est souvent pas trés legere)

Tu veux dire, que parfois il est bon de ne pas avoir d'index ?

J'ai ajouté un champ INDEX, comme un autre sauf qu'il est index, d'ailleurs il est même à 0 partout, cela sert à quelque chose ?

Merci

[Vincent]

alors les différences (de tete, j'ai plus mes cours d'université a porté de main ) :

- primary : c'est la clé primaire, c'est un identifiant unique et il fait fonction d'index

- unique : pour obliger que dans cette colonne, ton champs ait une valeur unique.

- index : pour optimiser les requetes qui font un acces avec comme principal critere ce champs.

Ensuite, il est parfois bon de ne pas avoir d'index oui, quand la clé primaire suffit : si tu va toujours chercher tes enregistrements de type id / libelle dans une table avec comme critere l'id qui comme par hasard est la clé primaire, un index est totalement inutile pour le champs libellé.

Ton nouveau champs INDEX ne sert strictement a rien. Il faut plutot cocher la case 'index' dans le champs qui est utilisé comme critère dans tes requetes de type select.

[Vincent]

trouvé sur phpfrance

Une fois votre table créée, pensez à ajouter des index sur les champs qui sont souvent utilisés dans les comparaisons et le tri. Nous expliquerons comment les utiliser en détail dans un prochain tutorial. Pour l'instant, vous pouvez consulter le manuel.

Il ne faut cependant pas en abuser. Ajoutez uniquement les index vraiment utiles car ils occupent de l'espace disque et les opérations d'insertion et de modification sont ralenties. MySQL risque également d'avoir du mal à optimiser les requêtes si il y a trop d'index.

j'espère que ca t'aidera !

[Berberber]

Merci, tout ça à l'air trés clair, je vais étudier tout cela.

[Vincent]

hop un lien de plus :

Vitesse des requêtes SELECT

[valdo]

Pour accélérer une requète, il faut:

1) placer des index sur les champs qui sont accédés par le SELECT, notamment en cas de test d'égalité

2) diminuer la taille des champs, pour baisser le temps de calcul de l'index.

3) choisir le bon type pour chacun des champs.

4) mettre un cache MySQL conséquent

5) diminuer la taille de la structure renvoyée, en n'utilisant pas un * là ou on peut choisir une liste de colonnes

6) utiliser les transactions, en cas d'INSERT en chaine

7) avoir plusieurs procs

8) avoir de la RAM

9) éviter un serveur surchargé

EDIT: Ah oui, éviter les passages fréquents entre PHP et MySQL, là ou une simple opération dans MySQL fait l'affaire. transférer des données du middleware à PHP, ça prends du temps.

EDIT 2: Sans compter qu'il faut pas mettre + d'index qu'il n'en faut, sinon les INSERT prennent trop de temps

Je crois qu'il y a à peu près tout

Valdo

Modifié 24 Janvier 2005 par valdo

[Berberber]

Avez vous une idée comment rendre plus rapide cela :

SELECT numero FROM recette ORDER BY rand() LIMIT 1;

cela apparait toujours dans mes requetes lentes.

[PascalC]

Tiens ça devrait t'aider :

http://www.chevrel.org/fr/optimiser/phpmysql/#p9

[Anonymus]

Le lien ci-dessus est très intéressant, s'il donne les explications pour l'hébergeur Online, ces explications sont valables pour tous les hébergeurs..

En plus, ils sont assez sencés, on sent bien qu'il a 'mouliné' son site dans tous les sens.

Si vous avez encore des problèmes de lenteurs sur votre site après avoir réglé tous ces problèmes, alors changez d'hébergeur.. (ou prenez une offre plus importante)

[Portekoi]

Les index se sont pas QUE contenu dans les clauses where... Ils le sont aussi dans un INNER.

Il faut donc bien créer ces index afin d'améliorer les jointures.

++

Portekoi

[MarvinLeRouge]

Lu je sais plus où : utiliser join (left, right, inner, outer) plutôt que where pour les jointures car le where oblige à un produit cartésien complet entre les tables concernées avant tout test, ce qui n'est pas le cas de join.

[Ex-floodeur]

4) mettre un cache MySQL conséquent

comment on fait ?