Bonjour
Mon problème, est les requêtes en lecture avec critère(s) et index.
Depuis le début de mon site ( voir profil ), je suis fidèle à MySQL, format IsAM.
MySQL, semble traiter les index de cette façon :
Il prend ( suivant les statistiques d'utilisation ), l'index dont la cardinality est la plus faible.
Moi, j'en suis réduit à avoir deux index multiples séparés ( entre autres ) sur la table COURSES :
IX_NUMCRS(NUMCRS) NUMCRS est le numéro d'index des lignes d'une course ( plusieurs lignes par course. )
IX_NUMCH(NUMCH) NUMCH idem pour celui d'un cheval ( Table : CHEVAUX(NUMCH PRIMARY KEY, NOMCH) en gros ).
Mais... J'ai des requêtes MySQL faisant intervenir ces deux index, ou bien l'un ou l'autre. Là est le hic.
Si je met un index PRIMARY KEY(NUMCRS, NUMCH) ( c'est possible ), et supprime donc le deuxième index ( IX_NUMCH ) ci-dessus, la charge CPU explose à plus de 100% ( d'après la commande "top" de Debian ).
Il y a donc un problème récurrent d'utilisation des index par MySQL.
D'autre part :
Avec ces deux index ci-dessus ( séparés ), des requêtes en lecture avec ces deux critère ( WHERE et/ou GROUP BY ou ORDER BY ), utilisent un seul index ( caractéristique de MySQL ).
D'où mon besoin éventuel, de changer de SGBD ( autre que MySQL, qui puisse gérer plusieurs index en même temps ).
A la limite je laisse ces deux index ci-dessus, là le seul problème, est que mon site a plus que 1500 visites/jour ( en général ), et que MySQL fait un verrouillage ( locking ) de tout le contenu des tables à la lecture ( il me semble ).
Ceci parce que le moteur de mes tables est : IsAM, et non pas InnoDB, qui lui met des locks au niveau row.
Je ne fais aucune utilisation de glob et fulltext et autres cochonneries, donc je pourrais convertir toutes mes tables en mode InnoDB.
Mais... Si je fais celà, est-ce que ma charge CPU ( ou bien espace RAM ) ne va-t-elle pas exploser, pour cause de requêtes simultanées, alors qu'actuellement les requêtes ( à cause des locks ) se font plus ou moins en suivant ?
Mon MySQL est la version 5.5 sous Debian Wheezy ( j'ai un VPS OVH Classic 4, 8Go RAM, CPU 4 coeurs je crois ).
Donc.. Que faire : Convertir en InnoDB pour gérer les accès concurrents, ou choisir quel autre SGBD ?
J'ajoute... Que mes requêtes sont en lecture.
Merci beaucoup de vos réponses par rapport au choix :
1- IsAM ou InnoDB, ou
2- MySQL ou quel autre SGBD ?
Respectueusement.
Mon problème, est les requêtes en lecture avec critère(s) et index.
Depuis le début de mon site ( voir profil ), je suis fidèle à MySQL, format IsAM.
MySQL, semble traiter les index de cette façon :
Il prend ( suivant les statistiques d'utilisation ), l'index dont la cardinality est la plus faible.
Moi, j'en suis réduit à avoir deux index multiples séparés ( entre autres ) sur la table COURSES :
IX_NUMCRS(NUMCRS) NUMCRS est le numéro d'index des lignes d'une course ( plusieurs lignes par course. )
IX_NUMCH(NUMCH) NUMCH idem pour celui d'un cheval ( Table : CHEVAUX(NUMCH PRIMARY KEY, NOMCH) en gros ).
Mais... J'ai des requêtes MySQL faisant intervenir ces deux index, ou bien l'un ou l'autre. Là est le hic.
Si je met un index PRIMARY KEY(NUMCRS, NUMCH) ( c'est possible ), et supprime donc le deuxième index ( IX_NUMCH ) ci-dessus, la charge CPU explose à plus de 100% ( d'après la commande "top" de Debian ).
Il y a donc un problème récurrent d'utilisation des index par MySQL.
D'autre part :
Avec ces deux index ci-dessus ( séparés ), des requêtes en lecture avec ces deux critère ( WHERE et/ou GROUP BY ou ORDER BY ), utilisent un seul index ( caractéristique de MySQL ).
D'où mon besoin éventuel, de changer de SGBD ( autre que MySQL, qui puisse gérer plusieurs index en même temps ).
A la limite je laisse ces deux index ci-dessus, là le seul problème, est que mon site a plus que 1500 visites/jour ( en général ), et que MySQL fait un verrouillage ( locking ) de tout le contenu des tables à la lecture ( il me semble ).
Ceci parce que le moteur de mes tables est : IsAM, et non pas InnoDB, qui lui met des locks au niveau row.
Je ne fais aucune utilisation de glob et fulltext et autres cochonneries, donc je pourrais convertir toutes mes tables en mode InnoDB.
Mais... Si je fais celà, est-ce que ma charge CPU ( ou bien espace RAM ) ne va-t-elle pas exploser, pour cause de requêtes simultanées, alors qu'actuellement les requêtes ( à cause des locks ) se font plus ou moins en suivant ?
Mon MySQL est la version 5.5 sous Debian Wheezy ( j'ai un VPS OVH Classic 4, 8Go RAM, CPU 4 coeurs je crois ).
Donc.. Que faire : Convertir en InnoDB pour gérer les accès concurrents, ou choisir quel autre SGBD ?
J'ajoute... Que mes requêtes sont en lecture.
Merci beaucoup de vos réponses par rapport au choix :
1- IsAM ou InnoDB, ou
2- MySQL ou quel autre SGBD ?
Respectueusement.