Je suis en généralement plutôt content de MySQL : c’est simple et stable, ça fonctionne bien. Mais il reste encore du travail pour que les messages d’erreur soient explicites. Petit résumé d’une frayeur causée par un message d’erreur approximatif.

Une de mes tables a une tendance marquée à la fragmentation, ce qui a pour conséquence de faire gonfler artificiellement sa taille et de faire baisser les performances de certaines requêtes. Je dois donc de temps à autre la défragmenter. Pas de problème : je commence par regarder la taille sur le disque du fichier .ibd (il s’agit d’une table InnoDB sur un serveur pour lequel innodb_file_per_table est activé). Quand la table est défragmentée, elle fait environ 8 Go :

# cd /data/mysql/main_revshare
# du -sh bris_statistic_video.ibd
11G bris_statistic_video.ibd

Pas de doute, une séance de défragmentation …

Les vacances étant terminées, nous allons boucler notre tour de vue des index inutiles en voyant quels outils vont nous aider à découvrir les index qui peuvent être supprimés. Le dernier article présentait en effet des indications qui fonctionnent généralement bien mais qui ont l’inconvénient de demander beaucoup de travail manuel et de laisser de côté tout un pan d’index qui peuvent être inutiles : ceux qui ne sont pas en doublon ni redondants, qui n’ont pas une cardinalité faible mais qui ne sont tout simplement pas utilisés par l’application.

Idée générale

Si vous avez bien lu l’article précédent, vous avez probablement remarqué que la principale difficulté est qu’il n’existe quasiment jamais de règle absolue permettant de savoir à coup sûr qu’un index est inutile (exception notable : les index en doublon repérés par mk-duplicate-key-checker et qui peuvent être supprimés dans 99% …

Après avoir constaté dans les articles précédents que les index inutiles causent des baisses de performances non négligeables, nous allons voir dans cet article qu’il n’est pas aussi simple qu’il y paraît de déterminer si un index est utile ou non, même si dans certains cas la réponse semble évidente.

A première vue, trois catégories d’index sont bien placés pour être qualifiés d’inutiles : les index en doublon, les index redondants et les index à faible cardinalité. Regardons chaque catégorie en détail.

Index en doublon

Les index en doublon sont simplement ceux qui sont définis plusieurs fois. Un exemple simple pour commencer :
CREATE TABLE t (
  id int(11) DEFAULT NULL,
  KEY a (id),
  KEY b (id)
);

Notons que MySQL n’empêche en aucun cas ce genre de définition erronée.

Un autre …

Dans l’article précédent, nous nous étions demandés quelle était la dégradation des performances en écriture quand on ajoute des index. On peut élargir la réflexion en se penchant sur les conditions qui améliorent ou diminuent la vitesse d’écriture dans une table.

Avant de commencer de nouvelles expérimentations, rappelons les conditions du test. La table utilisée a la structure suivante :

CREATE TABLE (
  id int(11) NOT NULL AUTO_INCREMENT,
  col_a varchar(30) NOT NULL DEFAULT '',
  col_b varchar(30) NOT NULL DEFAULT '',
  col_c varchar(30) NOT NULL DEFAULT '',
PRIMARY KEY (id)
);

et nous cherchons à insérer un millions de lignes à l’aide de la commande LOAD DATA INFILE.

Rappelons aussi que pour améliorer les performances en …

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 …

Voici les réponses de la 2è partie de notre quiz. Là encore, des commentaires expliquent rapidement les réponses.

16- a : Le nom d’hôte n’étant pas spécifié, ce sera donc localhost. Et pour MySQL, cela indique que le client cherche à se connecter à travers une socket : le numéro de port est ignoré. Pour que le port soit pris en compte, il faut ajouter soit -h=127.0.0.1 soit –protocol=tcp

17- b : Conséquence : quand MySQL a besoin de créer une table temporaire de manière interne (pour un tri par exemple) et que la table contient un champ TEXT ou dérivé, elle est automatiquement créée sur disque et risque de poser des problèmes de performance

18- b : Et malheureusement, la taille du tablespace ne diminue pas !

19- a : Seuls les index des tables MyISAM peuvent être mis en cache par le serveur, les données ne peuvent l’être que par l’OS, ce qui est beaucoup moins efficace

Après notre petit échauffement avec les 15 premières questions du quiz, voici la tant attendue deuxième partie ! Bon courage et à bientôt pour la deuxième série de réponses !

16- Sur un serveur Linux, deux instances de MySQL sont installées, l’une sur le port 3306 et l’autre sur le port 3307. Avec la commande mysql -uroot -p -P3307, sur quelle instance se connecte-t-on ?

1. a) L’instance écoutant sur le port 3306

1. b) L’instance écoutant sur le port 3307

17- Pour une table MEMORY, quelle est l’affirmation suivante qui est vraie ?

1. a) Les tables ne peuvent pas contenir plus d’un million de lignes

1. b) Les colonnes de type TEXT et dérivées ne sont pas autorisées

1. c) Les données ne peuvent pas être répliquées vers un serveur esclave

18- L’option innodb_file_per_table étant …

Et voici comme promis les réponses de la 1ère partie du quiz. Dans la mesure du possible, j’ai ajouté quelques petits commentaires pour expliquer le pourquoi du comment.

1- b : Toutes les ressources doivent etre étanches entre les instances

2- a : MyISAM garde dans ses méta-données le nombre de lignes de la table

3- b : InnoDB remplit d’abord le 1er fichier, puis le 2nd, on ne peut pas parler de distribution des écritures

4- c : Certains changements de droits n’affectent pas les sessions déjà ouvertes

5- a : Le tablespace principal contient des informations indispensables au bon fonctionnnement d’InnoDB, meme avec innodb_file_per_table

6- c : La réplication ne constitue pas une sauvegarde

7- a : Depuis MySQL 5.1 et la fonctionnalité de plugins, les versions d’InnoDB …

La rentrée est passée depuis quelques semaines, et dbnewz vous propose un petit quiz pour faire le point sur vos connaissances en MySQL. Ce quiz en 2 parties contient un total de 30 questions qui abordent les principaux domaines de notre base de données favorite : réplication, sauvegarde, performance des requêtes, installation, moteurs de stockage, outils…
Tous les documents sont bien sûr autorisés !
A vos marques, prêts ? Partez …

1- Quand on installe deux instances de MySQL sur la même machine hôte, les deux instances ne peuvent pas partager le même port, mais peuvent partager la même socket.

1. a) Vrai

1. b) Faux

2- Quelle est la requête dont l’exécution est immédiate, la table t utilisant le moteur MyISAM et id étant la clé primaire ?

1. a) SELECT COUNT(*) FROM t

1. b) SELECT COUNT(*) FROM t WHERE id > 5

Pour ce second volet de notre série consacrée aux outils d’analyse de requêtes lentes, nous allons nous pencher aujourd’hui sur mysqlsla, qui est un script Perl disposant de nombreuses options d’agrégation et de filtrage.

Commençons par l’installation du script. Rien de plus simple, il vous suffit pour commencer de télécharger et de décompresser une archive de l’outil, disponible ici. Ensuite, des classiques

$ perl Makefile.PL
$ make
# make install

vous permettent d’installer le script. Notez, point agréable, qu’une page de man est intégrée. Si vous cherchez la syntaxe d’une option, un man mysqlsla vous dispensera donc bien souvent d’aller faire un tour sur le site du projet.

mysqlsla est plus généraliste que …