dasini.net – Journal d'un expert MySQL

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.

2/ FTS ou FIS

Avant de répondre explicitement à la question, un petit zoom sur l’une des nombreuses nouveautés de MySQL 5.6. La commande EXPLAIN s’est enrichie de la clause format=json. Elle permet d’avoir une version un peu plus détaillée que l’EXPLAIN classique.

Query 1/ EXPLAIN format=json SELECT d,avg(price) FROM bills GROUP BY d\G

MySQL utilise un optimiseur à base de coûts. Le plan d’exécution de la requête choisit est celui dont le coût est le plus faible. Ce dernier peut être visualisé grâce à la variable Last_query_cost.
Son unité est le coût (encore lui) des accès aléatoires en lecture de pages de 4ko.
Étrangement cette variable est assez peu/mal documentée. Voici ce qu’on retrouve dans la doc officielle de MySQL
Je cite:
Last_query_cost
The total cost of the last compiled query as computed by the query optimizer. This is useful for comparing the cost of different query plans for the same query. The default value of 0 means that no query has been compiled yet. The default value is 0.Last_query_cost has session scope.
TheLast_query_cost value can be computed accurately only for simple “flat” queries, not complex queries such as those with subqueries orUNION. For the latter, the value is set to 0.

La valeur de Last_query_cost est parfois déconcertante, même avec MySQL 5.6. Voyez par vous même…

Les Viadeo Tech Days !
Une conférence qui vous donnera l’occasion d’échanger avec nos équipes de développement et de tout savoir sur les environnements à forte charge.
Rendez-vous les 20, 21 et 22 novembre 2012 à Paris pour 3 nocturnes animées par nos meilleurs ingénieurs.

Viadeo vous donne rendez-vous les 20, 21 et 22 novembre 2012 à Paris à l’occasion des Tech Days.

Au programme des conférences:
– MySQL avec MHA
– HDFS HA
– Neo4J
– Puppet
– UX
…
http://techdays.viadeo.com/

Un comportement bizarre m’a été remontée par un collègue.

J’ai une table qui contient des IDs (pas la clé primaire):

SELECT DISTINCT ID FROM Connection WHERE…\G

*************************** 1. row ***************************

ID: 12345678

J’utilise la fonction CONCAT pour concaténer une chaîne de caractères et les IDs de la table:

Le problème du jour, une table qui contient (entre autre) 2 colonnes de type entier non signé ( NombPart & NombInscr).
Une requête, qui fait la soustraction entre NombInscr et NombPart, pour remplir une autre table à la volée :
CREATE TABLE …
SELECT … NombInscr – NombPart as NombAbs …
FROM … ;

Et là, c’est le drame…
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in ‘(NombInscr – NombPart)’

Ce lundi 04 juin 2012, SUP’INTERNET et EPITECH organisent le PHP DAY, avec en guest star Rasmus Lerdorf, au CAMPUS TECHNOLOGIQUE DE IONIS EPITECH-SUP’INTERNET 14-16 rue Voltaire 94276 Kremlin Bicêtre Cedex

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 …