I N V I T A T I O N Meetup SkySQL Mercredi 12 décembre 2012 de 19h à 22h30   SkySQL Ab vous invite à une soirée de conférence et networking intitulée :   « MySQL, le Cloud et MariaDB »     Serge Frezefond, ex-MySQLer et consultant SkySQL, présentera les opportunités, avantages et freins à [...]

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 …

Le magazine Programmez N° 152 du mois de mai 2012 met en avant l’association LeMug.fr (MySQL User Group). Les informations ont été fournies par Christophe Villeneuve et Olivier Dasini, qui parlent des points suivants :   La création de l’association Son but Les différents évènements organisés De nombreux membres de l’association maintiennent différents sites parlant [...]

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 …

Last weekend Vadim from Percona published his MariaDB 5.3.4 benchmark results. As the new benchmark guy at Monty Program I take this oportunity to add some more results of my own.

One question in the comments to Vadim was if it is fair to compare MariaDB-5.3 with MySQL-5.5. Or if this comparison should be done with MySQL-5.1. The answer is: it does not matter much. MySQL-5.5 and MySQL-5.1 show very similar results in the Sysbench OLTP benchmark.

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: