I – Les statistiques de tables, pour quoi faire ?

Lorsque vous exécutez une requête SQL qui utilise un index, fait une jointure, ou d’autre opération complexe, MySQL va lire les statistiques lié aux index de ses tables, qui vont lui permettre de choisir le plan d’exécution optimal.

Pour InnoDB par exemple, ce comportement est contrôlé par les variables de type innodb_stats_% :

show variables LIKE 'Innodb_stats_%'; 
+--------------------------------------+-------------+
| Variable_name                        | Value       |
+--------------------------------------+-------------+
| innodb_stats_auto_recalc             | ON          |
| innodb_stats_method                  | nulls_equal |
| innodb_stats_on_metadata             | OFF         |
| …

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 …

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 …

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é!

"La simplicité est la sophistication suprême" (Léonard de Vinci).

Problème : vous avez à trouver, en seulement quelques secondes, un enregistrement unique parmi des milliards de milliards de possibilité et les seules informations dont vous disposez pour faire votre recherche sont de 17 à 35 attributs sur les 81 que contiennent la donnée tant convoitée… Est-ce possible ? Comment faire? De prime abord, ça semble impossible!

"Impossible n’est pas français" comme le dit le dicton (faussement attribué à Napoléon Bonaparte, vexé par le pessimisme de Jean Léonard, comte le Marois).

Il y a bientôt quelques années de cela, un de mes confrères de travail, …

Une manière d’identifier d’où provient des peaks de performance momentanés est de regarder les logs produit par MySQL, soit le slow query log et les binlog. Malheureusement (ou heureusement?), il est possible qu’un grand nombre de requêtes optimisées soit envoyées au serveur, et par conséquent, ne se trouve pas dans le slow query log. Le binlog s’avère donc une source plus fiable.

Comment faire? En utilisant mk-query-digest de la suite d’outil Maatkit. Cet outil permet d’analyse les logs générés par mysqlbinlog et crée un rapport complet de la situation. Il possède une multitude d’options que je vous invite à lire dans la doc officielle, mais voici comment l’utiliser dans sa forme la plus simple:

mysqlbinlog mysql-binlog.003161 | mk-query-digest --type binlog --report-format …

Lorsqu’on essaie d’améliorer une requête, que ce soit en modifiant le plan d’exécution ou en réécrivant la requête, on finit par choisir la variante dont le temps d’exécution est le plus faible. Encore faut-il que ce temps d’exécution ne soit pas falsifié par un quelconque cache. En cherchant comment désactiver les caches de MySQL, vous avez certainement trouvé la directive SQL_NO_CACHE. Cet article va faire le point sur ce que fait cette directive, mais également sur ce qu’elle ne fait pas.

Si vous avez déjà eu besoin de mesurer le temps que prend une requête sur un serveur inactif, vous avez sans doute déjà rencontré ce cas de figure :

1ère exécution :

mysql> SELECT COUNT(*) AS total,YEAR(birth_date) AS birth_year
FROM employees INNER JOIN salaries USING(emp_no)
WHERE first_name LIKE '%m%' AND salary > 50000 AND to_date < '2010-12-31'
GROUP …

Instrumenter son application correctement représente un pas important dans la recherche des performances optimales. De bons outils permettent également de gagner du temps, qui est toujours précis. Cet article va vous donner un exemple de la valeur ajoutée que peut procurer un bon outil : le simple fait d’obtenir un rapport précis sur un problème rencontré permet de résoudre en 5 minutes un gros problème de performance qui ne trouvait pas de solution depuis des semaines.

L’application en question dispose d’une table user permettant (surprise !!) de stocker les informations sur les utilisateurs. Cette table contient environ 30 millions de lignes et a l’allure suivante :


CREATE TABLE user (
  user_id int(11) NOT NULL AUTO_INCREMENT,
  login varchar(30) NOT NULL DEFAULT '',
  name varchar(50) NOT NULL DEFAULT '',
  col_a varchar(30) NOT …

J’oublie parfois à quel point les tables temporaires peuvent être pratiques. On tente de sortir des rapports avec des tables qui ne sont pas prévues pour ça. On écrit des requêtes inimaginables et souvent très lentes. Résultat: on perd notre temps.

La solution: les tables temporaires ! Ce n’est pas très coûteux et drôlement pratique. Au lieu de prendre 25 minutes à écrire “une” requête qui prend un temps énorme à s’exécuter, prenez 10 minutes pour écrire 2-3 requêtes simples qui utilisent des tables temporaires et sortez le même résultat en quelques secondes!

Et si c’est efficace, performant (surtout performant) et récurrent, pourquoi ne pas transformer ces tables temporaires en view ?