Vous pouvez consulter les photos du meetup Viadeo/LeMUG sur le compte FB du MUG:
https://www.facebook.com/media/set/?set=a.10150393843136937.345851.46154571936&type=3
MySQL, la base de données open source la plus populaire, inspire toujours autant les développeurs. David, propose un patch qui permet de créer un buffer pool supplémentaire pour InnoDB, qui est stocké sur un disque SSD ou de la mémoire flash.
Cette fonctionnalité créée un thread qui en tache de fond récupère les pages de données virées du buffer pool pour les copier dans le buffer pool supplémentaire du SSD au lieu du disque classique. L’idée étant d’éviter les accès au disque classique ( beaucoup plus lents notamment lors d’accès aléatoir?es).
De plus selon ses tests, ?????? les résultats restent également bien meilleurs avec une configuration SSD et un seul buffer pool.
Sysbench
Le cache est toujours à jour car en cas de modification d’une table, toutes les requêtes en relations avec cette table sont invalidées.
Le cache de requêtes est en général utile lorsque:
Les modifications sur les tables ne sont pas très fréquentes
Beaucoup de requêtes de lectures identiques
Utilisation de tables MyISAM. Moins intéressant pour InnoDB
Le but de cet article est d’optimiser une simple requête (SELECT avg(Population) FROM city GROUP BY CountryCode) et surtout de comprendre comment l’optimiseur procède, en étudiant les résultats donnés par les variables qui permettent de surveiller le serveur MySQL.
Il est possible d’influencer l’optimiseur pour qu’il choisisse d’utiliser ou de ne pas utiliser un index particulier. Les clauses à placer dans votre requête SELECT sont les suivantes:
USE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas si l’index est plus couteux qu’un full table scan)
FORCE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas …s’il ne peut pas l’utiliser 
)
IGNORE INDEX : n’utilise pas l’index passé en argument
