I – L’importance des performances single-threaded

La performance « single-threaded » représente la vitesse brute à la laquelle MySQL va exécuter une requête unique, sans qu’aucune autre ne soit exécutée en parallèle.

Elle dépend bien sur de votre materiel (vitesse du disque, de la mémoire, fréquence du processeur), mais aussi des optimisations présentes dans MySQL.

Il est important que ces performances soient bonne car cela permet bien sur d’exécuter plus rapidement des grosses requêtes, mais surtout d’avoir une réplication plus rapide des requêtes sur les serveurs « esclaves » (la majorité des requêtes étant exécutées de façon séquentielle).

II – Régression des performances au fil des versions de MySQL

Mark Callaghan de Facebook a constaté que les performances de MySQL …

MariaDB a annoncée il y a quelques semaines la sortie de MariaDB 10.

Voyons maintenant les principales nouveautés de cette version.

I – Possibilité NoSQL

A – L’engine CONNECT

Le NoSQL étant de plus en plus populaire (c’est WebScale !), MariaDB a introduit l’engine CONNECT permettant de se connecter à de nombreuses sources externes (des bases de données ODBC), ce qui peut effectivement être utile et …

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)

1. Un problème n’arrive jamais seul

Dans la deuxième partie de cet article (le premier article étant ici), nous nous sommes laissés sur un exemple extrême (i.e. une grille avec des lignes et des colonnes vides) afin de vérifier la validité et l’efficacité de la solution présentée dans un des pires scénarios envisageable :

Avant même de débuter, rappelez-vous qu’il est primordial d’exécuter la commande suivante dans votre session pour éviter d’avoir à attendre une éternité, que ce soit pour la …

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:

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:

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 …

Dans le premier article, nous avons vu combien il était facile de solutionner des grilles de sudoku avec une seule requête SQL. Malheureusement, c’était trop beau pour être vrai…

Avant de poursuivre, voici un outil utile pour se faciliter la tâche.  Pour ceux qui utilisent Smalltalk, vous pouvez vous aider du script suivant :

| uneTableOuVue uneStringSudoku stream estLePremier |

uneTableOuVue := 'sudoku_rows_view'.
uneStringSudoku := '.........134825697759364182397182564.........581476239825641973976538421.........'.

stream := ReadWriteStream on: String new.
stream
nextPutAll: 'SELECT * '; cr;
nextPutAll: 'FROM ';
nextPutAll: uneTableOuVue;
space; cr;
nextPutAll: 'WHERE'; cr.

estLePremier := false.
1 to: 9 do: [:r |
1 to: 9 do: [:c | | i |
i := (r-1)*9 + c.
((uneStringSudoku at: i) ~= $. and: [(uneStringSudoku …

Ainsi donc, cette première partie détaillera la méthode de base utilisée pour résoudre un sudoku en une seule requête SQL.  Et en passant, pour ceux que la petite histoire intéresse, vous trouverez ici un excellent article sur l’évolution du sudoku.

Pour nous faciliter la tâche, nous utiliserons des tables de type MyISAM pour commencer.  Dans le prochain article, nous ferons aussi en sorte que notre méthode ne retourne qu’une seule grille valide même dans le cas où plusieurs solutions existeraient.  Rappelons que notre objectif ultime est d’optimiser une base de données dans le but bien précis de solutionner une grille valide dans des délais raisonnables.  Mais pour cet article, nous nous contenterons de verser dans la facilité!