Les moteurs InnoDB et MyIsam

[joboy84]

Bonjour,

Je suis en train de faire une refonte de mon site et je pense à optimiser mes bases par la même occasion.

Je m'intéresse de près à InnoDB que je pourrais utiliser à la place de MyIsam pour certaines de mes tables, notamment pour la suppression des données membres en cascade.

D'après ce que j'ai pu lire à gauche et à droite, si je comprends bien, il est préférable d'utiliser InnoDB sur les tables à fortes requêtes de type: INSERT, UPDATE et DELETE. Par contre pour les select, MyIsam serait plus recommandé car plus performant au dessus de 4 thread...

Est ce bien cela?

Ma base contient entre autre les tables:

membres: toutes les infos sur les membres (requetes insert/update la plupart du temps)

Bannieres: contient les codes des bannieres de pubs (Beaucoup de requetes select)

1)Dans ce cas, je devrais plutôt utiliser InnoDB sur ma table membres et MyIsam sur la table bannières?

2)Ma table membres contient environs 30 champs. Serait il plus judicieux de créer plusieurs table est de mettre des jointures?

Par exemple, ne garder que les coordonnées: nom, prenom, date de naissance, sexe et e-mail dans la table membre, puis faire une autre table pour le solde de points du membre, puis une autre pour ses centres d'intérêts...

De même, d'une manière générale, qu'est ce que cela apporte de couper une table en plusieurs "morceaux"? Y a t il un gain de performance?

3) J'ai du mal à comprendre une chose dans les structures de bases de données. En général, on crée toujours un champ "id" qui est en auto incrémentation et en primary key. Je ne vois pas l'intérêt de ce champ? Car si je fais des requêtes en demandant toujours de comparer par rapport au pseudo (select nom from membres where pseudo=$pseudo), y a t-il un intérêt d'avoir le champ id en indiquant un index sur le champ pseudo et en le rendant unique?

Merci pour ces éclaircissement

Bonne journée

Merci

Jo

Modifié 16 Novembre 2008 par joboy84

[Dadou]

Concernant InnoBD et MyIsam, j'ai une préférence pour MyIsam, ne serait ce pour garder la possibilité d'utiliser "AGAINST ... MATCH" si tu veux réaliser un moteur de recherche sur ta table (en InnoDB ce n'est pas possible).

2) 30 champs, en effet, c'est plutôt énorme, et il serait effectivement bon de voir si certains groupes d'infos ne peuvent pas être regroupés dans des tables différentes.

3) Si ton champs pseudo est unique, effectivement, le champs id est moins intéressant, et il est plus interessant de créer la clé sur le champs pseudo, et que ce dernier soit indexé.

[Prélude]

Bonjour,

J'ai réalisé quelques tests qui peuvent éventuellement être utiles : http://www.magazine-jeux.com/Optimisation-MySQL.html

[Kioob]

<HS>Prélude : visiblement tes benchs ont été fait en mode "auto commit" non ? Ce qui expliquerait les perfs catastrophiques.

Je serais curieux de voir la même chose en tirant parti du transactionnel. On peut d'ailleurs rencontrer le même problème avec SQLite : sans transaction les perfs sont catastrophiques.</HS>