Sure, there are tools and script to help you fine tune your MySQL server but there’s nothing like using your brain.

Pythian has done a wonderful job of explaining what all those InnoDb-related variables in a series of articles…

Exposing Innodb Internals via System Variables: Part 1, Memory
Exposing Innodb Internals via System Variables: Part 2, I/O (structure and logs)
Exposing Innodb Internals via System Variables: Part 3, I/O (Table data)
…

Dernier volet dans notre série sur la configuration de MySQL, cet article va vous donner les clés pour paramétrer correctement et simplement InnoDB.

InnoDB est un moteur extrêmement complexe qui mériterait un livre complet pour expliquer son fonctionnement. Selon les versions, il peut exister plus de 80 paramètres pour contrôler son fonctionnement : pas question de les examiner tous ! Je vais me concentrer sur les 2 principaux, qui devraient suffir dans la majorité des cas.

Le 1er, innodb_buffer_pool_size, contrôle la taille du cache mémoire pour les données et les index. Il s’agit assurément du paramètre de base pour obtenir de bonnes performances InnoDB puisqu’il vous permet de remplacer de nombreuses lectures ou écritures sur disque par des lectures ou écritures en mémoire. Pour le configurer, c’est simple, essayez de mettre la valeur la plus élevée possible… Evidemment, il faut penser à …

Pour notre deuxième volet sur les points les plus importants à regarder lors de la configuration d’un serveur MySQL, nous allons nous occuper du cache de requêtes, de la réplication et de la journalisation. En route !

Cache de requêtes

Le cache de requêtes est une excellente idée des années 90 pour accélérer les performances des SELECT. Malheureusement ce cache n’est absolument pas scalable en terme de connexions simultanées, ce qui signifie que dans 99,9% des cas, les performances seront meilleures quand le cache est désactivée.

Par conséquent, le tuning du cache de requêtes est très simple, il vous suffit d’indiquer dans votre fichier de configuration :
query_cache = 0

Pour les plus curieux, sachez que la désactivation du cache de requêtes n’empêche pas le serveur d’utiliser la mutex d’accès au cache de requêtes : même désactivé, le cache de requêtes peut …

Des outils tels que mysql tuning primer ou mysqltuner proposent de vous aider à configurer correctement votre serveur MySQL. Il est vrai qu’il est facile de se perdre dans la profusion d’options disponibles. Pourtant les recommendations de ces outils sont bien souvent complètement absurdes ! Il est bien plus fiable de connaître les grandes lignes de la configuration du serveur pour obtenir rapidement un paramétrage correct. Je vous propose dans cette série d’articles de faire le tour des principales variables à regarder.

bind-address
Cette variable permet les connexions TCP à l’adresse IP indiquée. C’est la 1ère variable à regarder si vous constatez un problème d’accès et que les droits de l’utilisateur sont corrects.
En général, on utilise cette variable de 2 manières :
- bind-address = 127.0.0.1 pour n’autoriser que les connexions TCP en local
- en …

Le site dbnewz parle d'un point précis, touchant l'utilisation d'une base de données MySQL. L'article montre comment repérer les requêtes lentes et surtout les tracer.
L'article explique étape par étape comment activer le processus, identifier avec les fonctions de logs actives et bien sur, corriger pour optimiser les requêtes.

•  Tracer les requêtes lentes (0 visite)

Dans la grande majorité des applications, améliorer les requêtes qui mettent le plus de temps à s’exécuter s’avère en payant à tous les points de vue : les utilisateurs ont un meilleur ressenti de l’application grâce au gain en rapidité, la charge du serveur baisse car les requêtes lentes ont souvent pour origine un plan d’exécution coûteux et finalement le serveur est capable d’accepter plus de connexions qu’auparavant. Mais avant de pouvoir corriger ces requêtes lentes, encore faut-il les repérer afin de les analyser. C’est pourquoi je vous propose dans cet article de faire le point sur le slow query log, soit en français plus correct le journal des requêtes lentes.

Tout d’abord, il faut savoir que la version 5.1 a apporté pas mal de changements par rapport aux possibilités offertes jusqu’alors. Mais pour que les choses restent claires, nous allons commencer par présenter les options disponibles en 5.0. …

Dans le précédent post, nous avons optimisé une requête en abandonnant un des principes du SQL (dire au SGBD ce qu’on souhaite faire, mais pas comment le faire). Ici nous allons voir un exemple où le fait de penser en SQL va nous permettre de rendre performante une requête difficile à améliorer.

Nous repartons de la table du post précédent, remplie avec 500 000 enregistrements :
CREATE TABLE product (
product_id int(11) NOT NULL AUTO_INCREMENT,
category_id int(11) NOT NULL DEFAULT 0,
reference varchar(20) NOT NULL DEFAULT '',
name varchar(25) NOT NULL DEFAULT '',
sold int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (product_id)
) ENGINE=MyISAM;

Nous voulons, à partir de cette table de produits, trouver pour chaque catégorie le produit qui s’est le plus vendu.

Première idée : raisonner en terme de boucle, c’est-à-dire demander au SGBD de …

MySQLTuner est un script Perl qui produit un rapport sur la configuration de votre serveur MySQL et donne des pistes d’optimisation. On peut bien sûr s’interroger sur la manière dont l’analyse est faite et surtout sur la pertinence des recommendations. C’est exactement l’exercice qu’a fait Sheeri pour nous, en examinant le script sur toutes ses coutures.

Il en ressort que pas mal d’affirmations et de recommendations sont hardcodées et ne tiennent absolument pas compte des spécificités de votre base. Un exemple ? Si le cache de requêtes est désactivé, alors le script va systématiquement vous remonter qu’il s’agit d’un problème, même si vous avez sciemment désactivé ce cache.

A partir de toutes ces constatations, Sheeri a commencé à faire évoluer le script, en ajoutant pour l’instant quelques options intéressantes, comme celle permettant de formater le rapport de manière à le rendre facilement …

Nouveau volet de notre série consacrée aux index, la notion de sélectivité d’un index est ici à l’honneur.
Souvenez-vous du billet précédent : notre table de test contient 1 million de lignes et un champ “flag” à la cardinalité très faible : 2.

Cardinalité ? Sélectivité ? Avant d’aller plus loin, deux définitions s’imposent. Tout d’abord la cardinalité d’un index : c’est le nombre de valeurs uniques qu’il contient.

La sélectivité d’un index se calcule elle de la façon suivante :

Selectivité = Cardinalité(Idx) / Nombre total d’enregistrements dans la table
Résultat des courses notre index à une sélectivité de 2 /1 000 000 = 2e-6, …

Déjà trois semaines d’écoulées depuis que certains d’entre vous, les “héros”, ont posé leurs questions (oui il est possible de devenir un héros rien qu’en lisant dbnewz ! Les véritables héros sont d’ailleurs abonnés au tout nouveau flux feedburner )

Trois semaines d’attente, cela mérite un billet digne de ce nom, c’est parti.

Indexer, pourquoi ?

L’indexation peut avoir plusieurs buts :
- Accéder à ses données plus rapidement, les index sont en effet l’outil le plus puissant pour accélérer les temps d’exécution de vos requêtes jusqu’à parfois plusieurs centaines de % !
- Définir le degré d’unicité d’une colonne donnée : chaque champ doit-il …