Showing entries 1 to 10 of 18
Suivant 8 Entrées plus anciennes »
Displaying posts with tag: index (reset)
MySQL : quelques lectures

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.

[Lire plus]
The order of indexes

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, …

[Lire plus]
Les indexes non uniques

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, …

[Lire plus]
Méthodes de suppression des index inutiles

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% …

[Lire plus]
Index candidats à la suppression

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 …

[Lire plus]
Le coût des index inutiles – 2nde partie

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 …

[Lire plus]
Le coût des index inutiles

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 …

[Lire plus]
Instrumentation et performance

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 …

[Lire plus]
le trigger au secours des function-based index (FBI)

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) …

[Lire plus]
Influencer l’optimiseur de MySQL

Il est possible d’influencer l’optimiseur pour qu’il choisisse d’utiliser ou de ne pas utiliser un index particulier. Les clauses à placer dans votre requête SELECT sont les suivantes:

USE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas si l’index est plus couteux qu’un full table scan)

FORCE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas …s’il ne peut pas l’utiliser )

IGNORE INDEX : n’utilise pas l’index passé en argument

La plus part du temps, il se débrouille trés bien sans indications, mais parfois…

Dans cet exemple, j’utilise une table rental_daz inspirée de la table rental de la base de donnée sakila, voici sa structure:

12:14 daz$sakila> SHOW …
[Lire plus]
Showing entries 1 to 10 of 18
Suivant 8 Entrées plus anciennes »