dasini.net – Journal d'un expert MySQL

MySQL est connu pour ne pas être très performant avec les sous-requêtes. Ce n’est pas faux, et d’ailleurs c’est encore le cas avec MySQL 5.5. Le contournement consiste en général à réécrire la requête, certaines sous-requêtes pouvant être aisément réécrite en jointure.

C’est le cas de

SELECT a FROM T1 WHERE col IN (SELECT col FROM T2…) qui se transforme en

SELECT distinct a FROM T1 INNER JOIN T2 ON TI.col=T2.col WHERE …

La branche 5.5 de MariaDB est désormais stable (GA)

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.

Voici le support de la conférence de Colin Charles (Monty Program Ab) du Meetup MariaDB SkySQL / LeMUG.fr du 1er février 2012 à Paris.

MariaDB: The new M in LAMP

enjoy 🙂

SkySQL et Le MySQL User Group Francophone (lemug.fr) vous invitent à une rencontre MariaDB le 1 février 2012 à Paris, afin de découvrir ou approfondir vos connaissances de MariaDB, le SGBD 100% compatible avec MySQL développé par Michael « Monty » Widenius, le père fondateur de MySQL.

A cette occasion Colin Charles, MySQLer actuellement chez Monty Program Ab, animera une conférence intitulée: « MariaDB: The new M in LAMP »

Les équipes de MariaDB ont énormément travaillées sur l’optimiseur de la version 5.3, notamment en permettant une réelle utilisation des sous-requêtes.

Voici un effet visuel de ces optimisations:

Avec MySQL 5.5, l’utilisation de tables dérivées (type de sous-requêtes dans la clause FROM d’un SELECT), donne le plan d’exécution suivant:

Les vidéos du meetup Viadeo/LeMUG sont dispo:

Christophe Tibault : Opening keynote
Cédric Peintre : Planification et monitoring de mysqldump avec ZRM community
Stéphane Combaudon : Maatkit/Percona Toolkit en pratique
Marc Thomas : Passer de 10 000 à plus de 10 000 000 de paiements par mois
Olivier Dasini : Étude de cas : migration MySQL Latin 1 vers UTF-8

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