Lors d’une discussion à la cafèt, la question suivante fut posée : « Faire un ALTER TABLE avec plusieurs instructions est il plus rapide qu’un ALTER TABLE par instruction » ?
Les 2 protagonistes n’étant pas d’accord entre eux, c’est tout naturellement que je fus invité à donner mon avis.
La réponse me semble assez intuitive, mais comme des chiffres valent mieux qu’un longs discours…
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 cache, c’est ce que nous allons voir dans cet article.
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:
Dimitri KRAVTCHUK nous démontre avec une batterie de tests les évolutions en matière de performance apportées par MySQL 5.4:
* Huge performance improvement on InnoDB engine!
* MySQL 5.4.0 /Perf Version seems to be the most performant InnoDB implementation for the moment! (only except on the Read-Only workload @8cores where InnoDB plugin-1.0.3 is leading!)
* MySQL is outperforming PostgreSQL on my tests now!
* Regarding scalability, get a look at 8 vs 16 cores graphs, and you’ll see it’s the big step forward – no performance degradation on 16 cores is a very positive sign! and there is only 3 months distance between tests!
* LOCK_open needs a fix ASAP! 🙂
* Analyzing my test results, it’s too early to say InnoDB is scaling up to 16 cores, but the test results on 16 cores are already outperforming 8 cores, and I’m absolutely sure now – very quickly it’ll perform even better! so see you soon! :-))