Pour plus de clarté, nous allons nous intéresser à 2 tables dont le schéma est le suivant :

mysql> CREATE TABLE parent (
id INT NOT NULL AUTO_INCREMENT,
data varchar(20) NOT NULL,
PRIMARY KEY (id)
) ENGINE = InnoDB;

et

mysql> CREATE TABLE enfant (
id int(11) NOT NULL AUTO_INCREMENT,
id_parent int(11) NOT NULL,
data2 varchar(20) NOT NULL,
PRIMARY KEY (id),
CONSTRAINT fk_parent FOREIGN KEY (id_parent) REFERENCES parent (id)
) ENGINE=InnoDB

Remplissons ces 2 tables avec quelques lignes pour faire nos tests :

mysql> INSERT INTO parent (data) VALUES ('test');
mysql> INSERT INTO enfant (id_parent,data2) VALUES (1,'test');
mysql> INSERT INTO enfant (id_parent,data2) VALUES (1,'test2');

Que se passe-t-il maintenant quand nous essayons de supprimer la ligne de la table parente ?

mysql> DELETE FROM parent WHERE id = 1;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`test`.`enfant`, CONSTRAINT `fk_parent` FOREIGN KEY (`id_parent`) REFERENCES `parent` (`id`))

Eh oui ! Quand on n’indique pas de clause particulière dans la définition de la clé étrangère, cela équivaut à indiquer la clause NO ACTION (ON DELETE NO ACTION ON UPDATE NO ACTION). Et cette action interdit la modification d’une ligne de la table parente si cette ligne est en liaison avec la table enfant par la clé étrangère. A noter : le mot-clé RESTRICT est équivalent à NO ACTION.

Testons maintenant le 3è mot-clé possible : SET NULL. Et pour cela, modifions la structure de la table enfant :

mysql> ALTER TABLE enfant DROP FOREIGN KEY fk_parent;
mysql> ALTER TABLE enfant ADD CONSTRAINT fk_parent FOREIGN KEY (id_parent) REFERENCES parent(id) ON DELETE SET NULL ON UPDATE SET NULL;
ERROR 1005 (HY000): Can't create table 'test.#sql-4fb_33' (errno: 150)

Ici MySQL ne permet pas la création de la clé étrangère. En effet, avec SET NULL, si la table parente est modifiée, les lignes liées par la clé étrangère sont mises à NULL dans la table enfant. Ceci ne fonctionne bien sûr que pour des colonnes qui peuvent être NULL, ce qui n’est pas le cas dans notre exemple. Vous pouvez vérifier le fonctionnement de SET NULL en ajoutant une nouvelle colonne autorisant les NULL dans nos 2 tables.

Enfin, pour terminer, la célèbre action CASCADE transmet la modification faite sur la table parent vers la table enfant :

mysql> ALTER TABLE enfant ADD CONSTRAINT fk_parent FOREIGN KEY (id_parent) REFERENCES parent(id) ON DELETE CASCADE ON UPDATE CASCADE;
mysql> SELECT * FROM enfant;


+----+-----------+-------+
| id | id_parent | data2 |
+----+-----------+-------+
|  1 |         1 | test  |
|  2 |         1 | test2 |
+----+-----------+-------+


mysql> UPDATE parent SET id = id +1;
mysql> SELECT * FROM enfant;


+----+-----------+-------+
| id | id_parent | data2 |
+----+-----------+-------+
|  1 |         2 | test  |
|  2 |         2 | test2 |
+----+-----------+-------+

Il est également possible d’avoir des actions différentes pour la suppression et pour la mise à jour (par exemple ON DELETE RESTRICT ON UPDATE CASCADE).

Il reste encore 2 petites précisions à apporter :

• certains SGBD (c’est le cas de PostgreSQL par exemple) font une différence entre RESTRICT et NO ACTION : RESTRICT vérifie immédiatement l’intégrité référentielle alors que NO ACTION vérifie l’intégrité à la fin de l’exécution de la requete, ce qui laisse le temps à d’éventuelles triggers d’être déclenchés et à la contrainte d’intégrité d’être finalement respectée.
• il existe dans la norme SQL une 5è action possible : SET DEFAULT, mais elle n’est pas supportée par MySQL

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 retrouver pour chaque catégorie le produit qui s’est le plus vendu. Cela donne en SQL la requête suivante :

mysql> SELECT sql_no_cache pdt.*
FROM product pdt
WHERE sold =
(SELECT MAX(sold) FROM product
WHERE category_id = pdt.category_id);


On note la sous-requête corrélée, qui traduit en SQL notre idée de boucle à travers l’ensemble des catégories.

Temps d’exécution : très long… en effet j’ai arrêté l’exécution de la requête au bout de 20 mn, et toujours pas de résultat en vue à ce moment-là ! Un bon index est sans doute nécessaire…

Examinons le résultat de la commande EXPLAIN :

mysql> EXPLAIN SELECT...\G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
***************** 2. row *****************
id: 2
select_type: DEPENDENT SUBQUERY
table: product
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
2 rows in set (0,00 sec)


Effectivement, ce n’est pas fameux : pour chaque ligne de la table product, MySQL va exécuter la sous-requête, qui elle-même fait un scan complet de la table product… On est dans une situation bien pire qu’un CROSS JOIN, ce qui explique la lenteur constatée.

Un index composite sur (category_id, sold) va bien nous permettre d’améliorer la sous-requête…

mysql> ALTER TABLE product add index idx_category_sold (category_id,sold);
mysql> EXPLAIN SELECT ...\G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
***************** 2. row *****************
id: 2
select_type: DEPENDENT SUBQUERY
table: product
type: ref
possible_keys: idx_category_sold
key: idx_category_sold
key_len: 4
ref: test.pdt.category_id
rows: 500
Extra: Using index
2 rows in set (0,00 sec)


… mais il n’existe pas de moyen d’améliorer la requête principale.

Le temps d’exécution après ajout de l’index est maintenant de 2mn15, ce qui est encore loin d’être satisfaisant.

La limitation de notre requête, comme nous l’a montré la commande EXPLAIN, c’est que pour chacune des 500 000 lignes de la table, MySQL va devoir exécuter la sous-requête. Cela signifie que même en optimisant au mieux la sous-requête, celle-ci sera toujours exécutée 500 000 fois, ce qui est forcément couteux. Ajouter un index ne fait que limiter les dégâts, mais ne suffit pas pour obtenir des performances correctes.

La vraie solution à notre problème va consister à changer de point de vue sur la demande initiale formulée en langage courant, afin de pouvoir écrire la requête d’une toute autre manière, qui, espérons-le, sera plus efficace.

Nous allons donc raisonner de façon ensembliste. Avec notre table, il nous est possible de constituer deux ensembles : l’ensemble E1 des informations sur les produits (facile : SELECT * FROM product) et l’ensemble E2 des produits qui se sont le mieux vendus (facile aussi : SELECT category_id, MAX(sold) FROM product GROUP BY category_id). Si nous sommes capables de faire l’intersection entre E1 et E2, nous aurons résolu notre problème.

Or faire l’intersection de deux ensembles se traduit en SQL par une jointure entre deux tables. La solution est donc toute tracée :

mysql> SELECT sql_no_cache pdt.* FROM (
SELECT category_id, MAX(sold) as maxi
FROM product
GROUP BY category_id
) AS maxi_list
INNER JOIN product pdt
ON pdt.category_id = maxi_list.category_id
AND pdt.sold = maxi_list.maxi;


EXPLAIN nous montre comment est exécutée cette nouvelle requête :

mysql> EXPLAIN SELECT ... \G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table:
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra:
***************** 2. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ref
possible_keys: idx_category_sold
key: idx_category_sold
key_len: 8
ref: maxi_list.category_id,maxi_list.maxi
rows: 1
Extra:
***************** 3. row *****************
id: 2
select_type: DERIVED
table: product
type: range
possible_keys: NULL
key: idx_category_sold
key_len: 4
ref: NULL
rows: 1001
Extra: Using index for group-by
3 rows in set (0,05 sec)


MySQL exécute d’abord la sous-requête puis place le résultat dans une table temporaire, qui est jointe à la table product. A noter que la jointure se fait avec deux conditions, qui sont nécessaires toutes les deux.

Quel est le temps d’exécution de cette requete ? 0.06s… Pas besoin de commentaire, le gain est vertigineux !

Ces deux articles nous ont donc permis de voir que la manière dont une requête est formulée peut avoir des conséquences très importantes sur les temps d’exécution. Il n’existe pas de règle pour savoir si une requête est bien écrite ou pas, mais quand vous rencontrez une requête utilisant de bons index mais qui est lente, il peut être très intéressant de réfléchir à son sens pour trouver une réécriture qui sera performante.

Déterminer quels sont les index à poser pour optimiser la requête est une tâche relativement simple avec un peu d’habitude, mais que peut bien signifier la notion de réécriture d’une requête ?

Bien souvent, cette notion se limite à triturer les conditions de la clause WHERE de manière à isoler une colonne pour qu’un index soit utilisé. Et pourtant, il y a bien d’autres choses à imaginer, ce que nous allons aborder dans cet article.

Pour commencer, revenons très rapidement sur l’isolation des colonnes. Pour rappel, MySQL ne peut pas se servir d’un index sur une colonne si cette colonne fait partie d’une fonction.

Un petit exemple ?

mysql> EXPLAIN SELECT * FROM t WHERE UNIX_TIMESTAMP() - UNIX_TIMESTAMP(date_gen) > 180\G
           id: 1
  select_type: SIMPLE
        table: t
         type: ALL
possible_keys: NULL
          key: NULL
           ...

Ici, à cause de la fonction UNIX_TIMESTAMP(), MySQL refuse même d’étudier la possibilité d’utiliser l’index sur la colonne date_gen (ce qu’on voit dans la colonne possible_keys). Si par contre on réécrit un peu plus proprement notre condition et qu’on regarde de nouveau le plan d’exécution :

mysql> EXPLAIN SELECT * FROM t WHERE date_gen < DATE_SUB(CURRENT_TIMESTAMP,INTERVAL 180 SECOND)\G
           id: 1
  select_type: SIMPLE
        table: t
         type: ALL
possible_keys: idx_date
          key: idx_date
          ...

L’index sur la date est maintenant un candidat potentiel (toujours possible_keys) et il est utilisé (colonne key).

Ce genre de manipulations est en général simple à réaliser, venons-en donc à des techniques un peu moins connues.

Pour la suite de cet article, nous allons prendre des exemples avec une table product ayant les colonnes suivantes :

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;


Cette table a été peuplée avec 500 000 enregistrements grâce à supersmack.

Imaginons que nous voulons retrouver le premier produit qui a été inséré dans cette table dans la categorie n° 100. Facile :

mysql> SELECT MIN(product_id) FROM product WHERE category_id = 100;


Cette requête prend environ 0.9s à s’exécuter. Comme nous pensons que c’est un peu lent, nous allons essayer de l’améliorer, mais avec une contrainte forte : nous ne voulons pas modifier la structure de la table, et donc en particulier nous ne souhaitons pas ajouter un éventuel index.

La commande EXPLAIN nous apprend que le plan d’exécution choisi est un scan complet de la table, ce qui n’est pas une surprise puisque le seul index disponible (la clé primaire) ne risque pas de nous aider. Que faire alors ? Réécrire la requête bien sûr…

En réfléchissant bien, on peut se dire que si on scannait la clé primaire, on pourrait s’arrêter à la première valeur trouvée pour laquelle le champ category_id vaut 100. En effet, la clé primaire étant triée par ordre strictement croissant, la première valeur trouvée sera nécessairement la plus petite. D’où un premier essai :

mysql> SELECT MIN(product_id) FROM product USE INDEX(PRIMARY) WHERE category_id = 100;

Malheureusement, un appel à EXPLAIN montre que MySQL ne veut toujours pas utiliser la clé primaire, idem avec FORCE INDEX. Il va donc falloir être un peu plus persuasif…

Nous allons changer la requête en remplaçant le MIN() par un tri avec une clause LIMIT :

mysql> SELECT product_id FROM product WHERE category_id = 100 ORDER BY product_id ASC LIMIT 1;


Cette fois-ci, EXPLAIN nous indique bien un scan de la clé primaire. Extrait du résultat de la commande :

mysql> EXPLAIN SELECT product_id FROM product  WHERE category_id = 100 ORDER BY product_id ASC LIMIT 1\G
           id: 1
  select_type: SIMPLE
        table: product
         type: index
possible_keys: NULL
          key: PRIMARY

Et maintenant, le temps d’exécution passe à 0.01s, soit un gain notable.

Voilà donc un cas intéressant, où en comprenant bien comment sont stockées les données et les index, on peut réussir à réécrire une requête pour optimiser son exécution. Néanmoins, certains d’entre vous ont peut-être bondi en voyant cette réécriture.

En effet, nous avons tous appris que l’essence du SQL, c’est d’indiquer au SGBD ce qu’on souhaite trouver en laissant toute latitude au SGBD pour déterminer la manière la plus efficace d’effectuer la requête. Ici, non seulement, on indique comment faire la requête mais en plus, on perd le sens de la requête, l’appel à la fonction MIN() étant beaucoup plus explicite sur notre intention que la clause ORDER BY avec un LIMIT. Parfois, il faut pourtant juste être pragmatique et laisser tomber les grands principes au profit de la performance.

A noter avant de clore cette 1ère partie que la même requête initiale avec un MAX() n’aurait pas pu être réécrite d’une manière similaire. Notre technique de réécriture repose en effet sur le tri croissant de la clé primaire et il aurait fallu un tri décroissant sur la clé primaire pour que la technique fonctionne avec le MAX().

La seconde partie de cette article sera consacrée à des exemples de réécriture où le fait de penser en SQL sera bénéfique. Ouf, nous pourrons nous réconcilier avec les puristes du SQL.

Au programme des conférences dédiées à MySQL et MariaDB :

• mysqlnd / « MySQL native driver for PHP » : Les améliorations de la stack
• Au secours, ma base de données fait ramer mon application !
• LeMug : MariaDB, the future of MySQL avec Michael Widenius aka Monty
• Retour d’expérience sur l’utilisation de MySQL Chez Orange
• Réplication MySQL : retours d’expérience

Participez à cet événement et bénéficiez d’une offre exceptionnelle :

les deux journées du Forum PHP
+
l’adhésion 2009/2010 au MySQL User Group France

pour 140 euros au lieu de 200 euros!

Je me suis intéressé récemment aux instructions SELECT … LOCK IN SHARE MODE et SELECT … FOR UPDATE, qui sont censées permettre de verrouiller explicitement des lignes pour les tables InnoDB.
On comprend maintenant les deux premiers termes du titre

Pour mes test, je crée une table avec quelques enregistrements :
mysql> CREATE TABLE innotest (
id int(11) NOT NULL,
col varchar(10) DEFAULT NULL
) ENGINE=InnoDB;

mysql> INSERT INTO innotest (id,col) VALUES (1,'aaa'),(2,'bbb'),(3,'ccc'),(4,'ddd'),(5,'eee');

1er essai :
J’ouvre une 1ère session :
mysql> SELECT * FROM innotest WHERE col > 'c%' LOCK IN SHARE MODE;
+----+------+
| id | col  |
+----+------+
|  3 | ccc  |
|  4 | ddd  |
|  5 | eee  |
+----+------+
3 rows in set (0,00 sec)

Si je comprends bien, LOCK IN SHARE MODE pose un verrou partagé sur les lignes d’id 3, 4 et 5. Donc, normalement, si j’ouvre une autre session et que j’essaie de poser un verrou exclusif sur la ligne d’id 5, ma requête devrait être bloquée jusqu’à ce que je lève mon verrou partagé.

Essayons :

J’ouvre une 2nde session :
mysql> SELECT * FROM innotest WHERE id=5 FOR UPDATE;
+----+------+
| id | col  |
+----+------+
|  5 | eee  |
+----+------+
1 row in set (0,00 sec)

Hum ? La requête dans la 2nde session n’est pas bloquée, ce qui signifie que soit le verrou partagé n’a pas été posé, soit le verrou a bien été posé mais a été relâché d’une manière ou d’une autre.
Direction donc le manuel de référence.

Bon sang, mais c’est bien sûr ! Les verrous sont relâchés à la fin des transactions et comme je suis en mode AUTOCOMMIT, la transaction se termine tout de suite après chacun de mes SELECT.
Conclusion : il faut refaire la même chose, mais dans une transaction (3è terme du titre )

2è essai:
J’ouvre une 1ère session :
mysql> START TRANSACTION;
Query OK, 0 rows affected (0,00 sec)

mysql> SELECT * FROM innotest WHERE col > 'c%' LOCK IN SHARE MODE;
+----+------+
| id | col  |
+----+------+
|  3 | ccc  |
|  4 | ddd  |
|  5 | eee  |
+----+------+
3 rows in set (0,00 sec)

puis une 2nde session :
mysql> START TRANSACTION;
Query OK, 0 rows affected (0,00 sec)

mysql> SELECT * FROM innotest WHERE id=5 FOR UPDATE;

Cette fois, je ne récupère pas la main sur mon SELECT … FOR UPDATE car ce SELECT ne peut pas acquérir le verrou exclusif sur la ligne d’id 5 à cause du SELECT de l’autre session qui a déjà un verrou partagé sur cette ligne. Ouf ! Je vérifie bien que le SELECT … LOCK IN SHARE MODE a posé des verrous comme je le souhaitais.

Si maintenant, je fais un COMMIT dans ma 1ère session, le verrou partagé est levé et le SELECT … FOR UPDATE peut alors se terminer.

A noter que dans la 2ème session, je n’ai pas réellement besoin du START TRANSACTION, puisque ce sont les verrous posés par le SELECT … LOCK IN SHARE MODE qui m’intéressent ici.

Ce point étant clarifié, passons à une autre vérification : le LOCK IN SHARE MODE a-t-il bien verrouillé uniquement les lignes d’id 3, 4 et 5 ?

Facile : il suffit de répéter la même séquence que dans le 2è essai mais en modifiant la requête dans la 2è session pour demander un verrou exclusif sur la ligne d’id 1. Cette ligne n’étant pas censée être verrouillée, je dois pouvoir obtenir le verrou immédiatement.

3è essai :
1ère session :
mysql> START ...

2nde session :
mysql> SELECT * FROM innotest WHERE id=1 FOR UPDATE;

Et là, c’est le drame ! Le verrou exclusif ne peut pas être acquis et donc la requête est bloquée. Il n’y a qu’un seul suspect possible, c’est le SELECT … LOCK IN SHARE MODE de la 1ère session.

Comme bien souvent, pour comprendre ce qui se passe dans une requête, un petit coup d’EXPLAIN est bien utile :
mysql> EXPLAIN SELECT * FROM innotest WHERE col > 'c%' LOCK IN SHARE MODE\G
******************* 1. row *****************
id: 1
select_type: SIMPLE
table: innotest
type: ALL
...

Maintenant, tout est clair ! Le type ALL indique un full table scan, or comme InnoDB acquiert les verrous au fur et à mesure qu’il en a besoin, dans ce cas, il lui faut acquérir un verrou sur toutes les lignes de la table. Evidemment, ce n’était pas très facile à deviner…

Tout espoir est-il perdu de faire verrouiller par une transaction une partie des lignes et de faire verrouiller par une autre transaction une autre partie des lignes ? A priori, si InnoDB était capable dans mon 1er SELECT de trouver les lignes 3, 4 et 5 sans faire de full table scan, ça pourrait être possible.

Comment faire ce miracle ? Avec un index sur col, bien sûr ! (Et voilà, 4è terme du titre )

mysql> ALTER TABLE innotest ADD INDEX idx_col(col);

et on recommence la séquence du 3è essai :
1ère session :
…

2nde session :
mysql> SELECT * FROM innotest WHERE id=1 FOR UPDATE;

Aïe, ça bloque encore et toujours

Un EXPLAIN sur le SELECT … LOCK IN SHARE MODE montre pourtant bien que l’index est utilisé :
mysql> EXPLAIN SELECT * FROM innotest WHERE col > 'c%' LOCK IN SHARE MODE\G
************* 1. row ***********
id: 1
select_type: SIMPLE
table: innotest
type: range
possible_keys: idx_col
key: idx_col
...

Oui mais maintenant, le problème vient du 2è SELECT. Comme il n’y a pas d’index sur id, MySQL fait un full table scan pour résoudre la requête (c’est confirmé par un appel à EXPLAIN) et pose des verrous exclusifs sur toutes les lignes rencontrées…sauf que les lignes 3 à 5 ont déjà un verrou partagé : il n’est donc pas possible de poser le verrou exclusif, ce qui bloque toute la requête.

La solution passe là encore par un index, mais cette fois-ci sur id. Ou alors, en conservant uniquement l’index sur col, il faut réécrire la requête pour qu’elle fasse intervenir l’index, par exemple :
mysql> SELECT * FROM innotest WHERE name='aaa' FOR UPDATE;

Evidemment, dans la vraie vie, il n’est pas toujours possible de réécrire ainsi ses requêtes, mieux vaut donc poser les bons index.

Cerise sur le gâteau pour finir, en ne conservant que l’index sur col, on peut faire apparaître une jolie deadlock en pensant ne verrouiller que des lignes différentes :
1ère session:
mysql> START TRANSACTION;
Query OK, 0 rows affected (0,00 sec)

mysql> SELECT * FROM innotest WHERE col > 'c%' LOCK IN SHARE MODE;

2nde session :
mysql> SELECT * FROM innotest WHERE id=1 FOR UPDATE;

puis de retour dans la 1ère session :
mysql> SELECT * FROM innotest where col='bbb' LOCK IN SHARE MODE;

ce qui provoque dans la 2è session :
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Moralité de l’histoire : votre bonne conscience vous répète constamment que les index sont vitaux. Faites plaisir à votre conscience : posez des index ! (pertinents bien sûr…)

Pour essayer de pallier à tous ces défauts, Darren a créé un outil : Securich, installable sur tout serveur MySQL 5.1. Cet outil permet, à l’aide d’appels à des procédures stockées, de manipuler les utilisateurs et leurs droits. Attention tout de même, le développement de Securich a commencé il y a peu de temps et le code est encore expérimental. Il reste pas mal de fonctionnalités que Darren voudrait implémenter et quelques bugs gênants : par exemple, si vous installez Securich sur un serveur contenant des utilisateurs, Securich va effacer tous les utilisateurs sans vous en avertir…

L’initiative est en tout cas intéressante car il reste effectivement pas mal de travail pour que MySQL présente autant de fonctionnalités sur les utilisateurs et les droits que d’autres produits.

Sans entrer dans le détail des commandes (voir pour cela la page sur Launchpad), MySQL Sandbox permet de créer en une ligne de commande des environnements complets et variés : un serveur, plusieurs serveurs indépendants, un maître-plusieurs esclaves…Il est même possible de créer, toujours en une seule ligne, une réplication circulaire entre N serveurs ! Le script permet également de démarrer, arrêter, effacer chacun des serveurs ainsi créés ou de faire une opération pour tous les serveurs à la fois.

Ca faisait un moment que je voulais prendre un peu de temps pour voir ce qu’il était possible de faire avec MySQL Sandbox, maintenant c’est sûr : je vais m’y mettre !

A voir également sur le sujet : un précédent article d’Arnaud, sur dbnewz bien sûr !

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 lisible par un tableur : il devient ainsi plus facile de voir l’évolution de certains indicateurs dans le temps en lançant le script à intervalles réguliers. A suivre !

Quand on commence une application, un seul serveur SQL suffit généralement à absorber la charge. Si le trafic augmente et que les performances du serveur commencent à s’écrouler, on peut utiliser la réplication. Mais la réplication ne permet que d’augmenter le nombre de lectures possibles (read scaling) et pas le nombre d’écritures (write scaling). Cette limitation provient du fonctionnement même de la réplication car toutes les écritures doivent arriver sur le serveur maître. On peut alors imaginer de séparer les données selon certaines règles (dépendantes de l’application) de manière à avoir plusieurs masters sur lesquels on peut utiliser la réplication. Et voilà, nous venons d’inventer le sharding.

Giuseppe nous explique que le sharding est simple à mettre en place : il suffit de créer des règles permettant de dispatcher les données entre les différents masters. Malheureusement, le sharding est fragile : si, par exemple, vous changez les règles de dispatch, vous risquez de casser vos shards ! Pour simplifier le sharding, il existe un moteur de stockage récent, installable en tant que plugin pour MySQL 5.1 : Spider. Spider est basé sur le partitionnement et permet de créer des tables sur un serveur dont les données seront stockées sur des hosts distants. En gros, on utilise une pincée de partitionnement et une pincée de Federated…

Les démonstrations faites par Giuseppe montrent quand même que si Spider peut nous simplifier la tâche du sharding, la mise en place de tables avec Spider n’est pas si simple et demande un peu de doigté et de réflexion…

La désactivation du contrôle des clés étrangères est intéressante lorsque vous devez exécuter sur votre serveur MySQL un script de création de tables par exemple. Il se peut dans ce cas que l’ordre de création des différentes tables ne soit pas « logique ».

J’entends par là qu’une table A peut contenir une contrainte basée sur une clé étrangère référençant le champ d’une table B… qui n’existe pas encore ! La « logique » voudrait que les tables soient inscrites dans le script selon les liens qui existent entre elles mais cela n’est pas toujours le cas.

Cette opération de classement pouvant s’avérer fastidieuse à effectuer manuellement, vous pouvez vous affranchir des vérifications effectuées par le SGBD concernant les clés étrangères en utilisant la commande suivante :

mysql> SET foreign_key_checks = 0;

Vous êtes ainsi tranquille le temps de créer vos tables. Réactiver ce contrôle n’est pas plus compliqué :

mysql> SET foreign_key_checks = 1;

Le chapitre de la documentation correspondant aux foreign keys nous indique que c’est d’ailleurs la technique employée par mysqldump.