Slides du meetup
septembre 25, 2015
Comme promit, voici la suite de l’article Utiliser une sous-requête c’est mal ?
L’idée ici est de répondre aux interrogations de svar et d’en profiter pour explorer les nouvelles possibilités de la variante stable de MySQL qui possède l’optimiseur le plus avancé, c’est à dire MariaDB 5.5.
Préambule
En pré-requis, je vous invite à explorer la doc officielle de MySQL au sujet de la variable optimizer_switch, qui permet de sélectionner les algorithmes d’optimisation, ainsi que les différentes subtilités implémentées dans l’optimiseur de MariaDB.
La valeur par défaut sur MariaDB 5.5.30 de la variable optimizer_switch est:
Cela fait quelques jours maintenant que MySQL 5.6 est disponible pour la production. Un impressionnant travail a été effectué par les équipe d’Oracle, voici un petit résumé des principales évolution vu par Peter Zaitsev.
L’événement dans l’événement, c’est la « polémique » sur les performances de la 5.6, par rapport à MySQL 5.5 mais surtout par rapport à MariaDB 5.5.
Dimitri (Oracle), montre que MySQL 5.6 écrasent MySQL 5.5 et MariaDB 5.5. Axel (MariaDB), de son coté montre que la 5.6 est moins performante que MariaDB 5.5, ainsi que MySQL 5.5. Peter (Percona), de son coté montre que les perfs de MySQL 5.6 sont en retrait par rapport à celles de MySQL 5.5. Au passage, je note que Percona server 5.5 n’est pas testé… Last but not least, Mark (Facebook) , montre que sa version maison 5.1.63 patchée met tout le monde d’accord. Il montre aussi que le coût du performance schemas n’est pas négligeable.
Voici la suite du post MySQL 5.6 rock, dans lequel je test MySQL 5.5 & 5.6, MariaDB 5.3 & 5.5 et Percona server 5.5.
Pour cet article, toujours un bench. Le contexte est assez proche, à la différence près que cette fois les serveurs sont testés en lecture (65%) et écriture (35%).
Comme d’habitude, mon but n’est pas de connaître les possibilités maximales du serveur (d’autres le font mieux que moi), mais plutôt d’avoir une idée assez précise de leurs comportements respectifs dans un environnement le plus proche possible de ma prod.
pour ce test, les candidats sont, Percona 5.5, MariaDB 5.3 & 5.5, MySQL 5.5 et la dernière milestone de MySQL 5.6. L’idée est de voir comment se comporte les différentes versions dans un contexte I/O bounds ie un faible hit ratio du buffer pool (ou du moins le plus bas possible), en d’autres termes, simuler le comportement du serveur MySQL dans un environnement où la quantité de données est énorme (comme à Viadeo).
Selon le livre «Audit & optimisation, MySQL 5 – éditions Eyrolles», le cache de requêtes ou query cache est un système de cache mémoire interne à MySQL, transparent pour l’application, qui ne stocke que les requêtes SELECT et leurs résultats.
L’apport de ce cache est particulièrement dépendant de votre application. Il est coutume de dire qu’il est (très) pénalisant dans des environnements où les requêtes d’écritures sont nombreuses, notamment à cause de son mécanisme d’invalidation (et de problèmes de contentions de façon générale).
A l’opposé, il peut être intéressant de l’activer, dans des environnements à forte charges de lectures, si les mêmes requêtes reviennent très fréquemment, plus particulièrement lors de l’utilisation de tables MyISAM.
Cependant, un environnement à forte charge en lecture n’est pas une condition suffisante pour s’assurer de bonne performances avec le query cache, c’est ce que nous allons voir dans cet article.