MySQL TechDay, le programme

octobre 1, 2013

Le 10 octobre 2013, Le MySQL User Group Francophone (lemug.fr) et Oracle MySQL vous invitent au MySQL Tech Day à Paris.

A partir de 10h30, avec un programme exceptionnel !!! :

Overview: MySQL Innovation @Oracle @MySQL Connect
Xavier GERARD / Olivier ZEMRAG (MySQL France)

MySQL Performance: Latest improvements in MySQL 5.6 & 5.7
Dimitri KRAVTCHUK (MySQL Performance Engineering leader)

MySQL Optimizer: What is new? what is coming?
Guilhem BICHOT (MySQL Optimizer Engineering team)

50 tips to boost MySQL Performance
Arnaud ADANT (MySQL Support team)

MySQL Performance Schema: Overview / HOWTO
Dimitri KRAVTCHUK(MySQL Performance Engineering leader)

MySQL Performance Schema: Hands-on (live lab)

2

Utiliser une sous requête c’est mal ? (suite) part 1-3

mai 27, 2013

Comme promit, voici la suite de l’article Utiliser une sous-requête c’est mal ?

L’idée ici est de répondre aux interrogations de svar et d’en profiter pour explorer les nouvelles possibilités de la variante stable de MySQL qui possède l’optimiseur le plus avancé, c’est à dire MariaDB 5.5.

Préambule

En pré-requis, je vous invite à explorer la doc officielle de MySQL au sujet de la variable optimizer_switch, qui permet de sélectionner les algorithmes d’optimisation, ainsi que les différentes subtilités implémentées dans l’optimiseur de MariaDB.

La valeur par défaut sur MariaDB 5.5.30 de la variable optimizer_switch est:

0

Utiliser une sous-requête c’est mal ?

avril 23, 2013

Jusqu’en MySQL 5.5 inclus, l’utilisation de sous-requêtes peut, dans certain cas, être la cause de problèmes de performances (l’optimiseur est bien meilleur en MySQL 5.6, MariaDB 5.5 et MariaDB 10).

Récemment j’ai eu un souci en prod, après une MEP, avec une requête qui durait en moyenne plus de 1000 secondes…

Inutile de préciser que dans un environnement OLTP, application web plus précisément, ce n’est pas jouable, elle a donc été virée très rapidement (mais pas le développeur qui l’a créée…)

Alors passons sur le fait que ce genre de problème devrait être identifié avant d’arriver sur la prod, et voyons à quoi ressemble une requête qui peut prendre 45 minutes:

9

Full table scan vs Full index scan part2-2

janvier 30, 2013

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

2

Full table scan vs Full index scan part1-2

janvier 8, 2013
Tags:

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…

0

Optimiser un ALTER

mai 30, 2012

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…

2

Meetup MySQL Viadeo / LeMUG.fr, les photos

décembre 7, 2011

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

4

Un disque SSD comme buffer pour InnoDB

février 1, 2011
Tags:

MySQL, la base de données open source la plus populaire, inspire toujours autant les développeurs. David, propose un patch qui permet de créer un buffer pool supplémentaire pour InnoDB, qui est stocké sur un disque SSD ou de la mémoire flash.

Cette fonctionnalité créée un thread qui en tache de fond récupère les pages de données virées du buffer pool pour les copier dans le buffer pool supplémentaire du SSD au lieu du disque classique. L’idée étant d’éviter les accès au disque classique ( beaucoup plus lents notamment lors d’accès aléatoir?es).

De plus selon ses tests, ?????? les résultats restent également bien meilleurs avec une configuration SSD et un seul buffer pool.

Sysbench

0

MySQL Query cache

octobre 12, 2009
Tags:

Le cache est toujours à jour car en cas de modification d’une table, toutes les requêtes en relations avec cette table sont invalidées.

Le cache de requêtes est en général utile lorsque:
Les modifications sur les tables ne sont pas très fréquentes
Beaucoup de requêtes de lectures identiques
Utilisation de tables MyISAM. Moins intéressant pour InnoDB

15

Optimisation de requêtes: comprendre l’optimiseur de MySQL

février 18, 2009

Le but de cet article est d’optimiser une simple requête (SELECT avg(Population) FROM city GROUP BY CountryCode) et surtout de comprendre comment l’optimiseur procède, en étudiant les résultats donnés par les variables qui permettent de surveiller le serveur MySQL.

6