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 …
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 …
[Lire plus]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.
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:
Avec les sorties de MySQL 5.5.8 et de MariaDB 5.2.4, l’écosystème SGBDR open source se retrouve donc avec 3 bases (n’oublions pas MySQL 5.1.53) en GA. J’ai eu envi de voir le résultat des améliorations apportées par les équipes d‘Oracle sur la première version majeure post rachat (MySQL 5.5.8) et celles apportées par la communauté et les équipes de Monty program pour la version basée sur MySQL 5.1.53 (MariaDB 5.2.4).
De nombreuses optimisations ont eu lieu sur la version MySQL 5.5.8, ainsi que sur le moteur de stockage InnoDB. Idem pour MariaDB et la version InnoDB de …
[Lire plus]Dimitri KRAVTCHUK nous démontre, avec une batterie de tests, les évolutions en matière de performance apportées par MySQL 5.4:
mysqlslap : un utilitaire de test de charge et de performance
Disponible depuis MySQL 5.1.4, mysqlslap permet d’effectuer des tests de stress et de charge sur votre serveur MySQL. Vous pourrez alors tester les performances de votre SGBDR préféré, après, par exemple, une nouvelle installation, un changement d’architecture ou après avoir modifié des paramètres de configuration.
Créé pour devenir le meilleur ami des administrateurs de bases de données et des développeurs, le client mysqlslap envoie des requêtes au serveur MySQL en créant plusieurs connexions simultanées. A la fin de la simulation, un rapport de diagnostic est crée sur la sortie standard. Vous avez aussi la possibilité de l’écrire dans un fichier au format CSV utilisable …
[Lire plus]