Ce troisième article aura pour sujet l’utilisation des indexes invisibles en MySQL 8.0.14

MySQL 8.0 permet d’utiliser maintenant les indexes invisibles. Un index invisible n’est pas pris en compte par l’optimizer quand il fait le plan d’exécution de la requête.

Les indexes sont visibles par défaut. L’index invisible …

Vous cherchez des solutions à des problèmes 1000 fois rencontrés?  Il y a de grandes chances que vous trouviez ce qu’il vous faut ici!

Un excellent blogue consacré à MySQL sur lequel je suis tombé par hasard, lefred.be.

Un article portant sur l’erreur 1215 (« Cannot add foreign key constraint« ).

Les InnoDB Page merge & split expliqués en détail dans ce billet.

…

If you thought all you had to do was to declare a few indexes here and there and MySQL would magically be fast, you’ll be surprised reading this excellent article.

Classé dans:bases de données, database, MySQL, programming Tagged: index, MySQL, …

On vous a garroché la responsabilité d’une base de données qui s’apparente plus à un immense merdier qu’à quelque chose de structuré?

Vous vous dites qu’il faudrait tout d’abord vous débarasser du bois mort et éliminer tout ce qui est inutile, en commençant par tous ces indexes non uniques qui ne servent pas à grand’chose?

Ne désespérez pas : quelqu’un a fait le travail pour vous faciliter la tâche!

Classé dans:MySQL Tagged: index, indexes, …

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 …

On vous a tout le temps dit et redit que les index étaient indispensables pour les performances en lecture d’une base de données et vous avez eu droit à des exemples spectaculaires où les temps de réponses sont divisés par 10 000 ou par 1 000 000 rien qu’en ajoutant un index judicieux. Bien. On vous a également prévenu que chaque index posé dégrade les écritures et qu’il ne faut donc pas en abuser. Mais vous a-t-on déjà montré quel type de dégradation en écriture on peut attendre quand on ajoute un index ? C’est ce dont nous allons parler dans cet article.

Prenons une table InnoDB toute simple :


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)
) ENGINE=InnoDB;


et testons l’influence des index …

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 …

Constat : les FBI (function-based index) ne sont pas disponibles en MySQL.

Comment faire dans ce cas pour obtenir par exemple l’équivalent de l’index suivant ?

CREATE INDEX idx_str_len ON my_table (length(str));

Une des solutions les plus simples consiste à utiliser un trigger qui assurera la mise à jour d’une colonne supplémentaire que l’on créera dans la table cible.

Partons de la table suivante :

CREATE TABLE `t` (
`id` mediumint(8) unsigned NOT NULL auto_increment,
`date` timestamp NOT NULL,
`str` varchar(100) NOT NULL default '0',
PRIMARY KEY  (`id`)
) ENGINE=MyISAM;

Le but est de pouvoir obtenir une réponse rapide à la requête suivante :

select sql_no_cache count(*) from t where length(str) …