Quel SGBDR plus rapide que MySQL et gratuit ?

Bonjour

J'ai un VPS Classic 4 OVH. ( 8 Go RAM + 100 Go HD ).

Mon site utilise UN SGBDR ( Système de Gestion de Base de Données Relationnelles ) : MySQL sous Debian 8 Wheezy.

Mon moteur est InnoDB, qui permet plus les accès concurrents que MyISAM.

Mon serveur Apache 2.4.10 ( avec le module mpm et php-fpm ), a des temps de réponse qui varient entre 0,40 sec, et 2,4 sec ( très rarement , le plus souvent < 1,0 sec ).

La RAM utilisée reste en dessous de 15%, et la charge CPU < 5%. ( Console de Gestion OVH ).

Mais.. La commande 'top' me donne jusqu'à 60 ou 70% pour la RAM par MySQL ( mesures très ponctuelles ), et un CPU correct faible. Le PHP-FPM me donne ( par le top ), dans les 25% ( ponctuel aussi ).

Le problème, est la gestion des index par MySQL.

Lors d'une requête MySQL avec index(es), MySQL attribue un poids aux différents index de la requête, ces poids sont une mesure de la quantité estimée de données qu'il faut charger pour satisfaire la requête.

Comme MySQL n'utilise qu'un seul index par requête, il choisit celui ayant le plus faible poids ( = moins de quantité de données à lire ).

Moi, j'étais j'étais habitué au SGBDR ORACLE V7 ( étudié lors de mon ( vieux ) stage de 1977 ), et au concept MERISE II suivant lequel une donnée indexée est accessible directement.

MySQL ayant une gestion ( à l'exécution ) des index, qui me semble un peu vieillotte, n'y aurait-il pas d'autres SGBDR disponibles ( gratuits de préférence ), sous Debian Wheezy, qui gèrent correctement les index, et qui ne se mette pas - comme MySQL - à parcourir toute une table MySQL, sous le prétexte que la requête comporte plusieurs index ?

Je ne peux pas optimiser plus mes requêtes, je suis obligé parfois, de faire des requêtes sur plusieurs tables MySQL, ou bien souvent, sur plus d'un seul index.

Super merci pour vos réponses.

Respectueusement.

 

Rebonjour

Je me répond.

Il me semble, qu'au moins un type de requête dans mon cas, est mal indexée.

Celui avec : FROM COURSES WHERE NUMCRS... AND REUNION... AND COURSE...

NUMCRS dépendant de DATECRS ( autre champ dans ma table COURSE ), je vais faire un champ ID VARCHAR(10), contenant la date et le numéros des réunions et des courses.

Cet ID ( en index multiple ), sera nécessairement de poids faible, et de toute façon, réduira la requête à un seul WHERE.

Moi qui était obnubilé par le fait de faire des index numériques...

Quant au reste, l'essentiel est d'avoir des requêtes indexées, dont le poids soit faible.

Pas besoin de changer de SGBD semble-t-il.

Respectueusement.