INSERT [LOW_PRIORITY] [IGNORE] [INTO] nom_de_la_table [(liste des colonnes)] SELECT ...

La requête INSERT ... SELECT permet de rapidement insérer dans une table un grand nombre de lignes d'une ou plusieurs autres tables.

INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID FROM tblTemp1 WHERE
tblTemp1.fldOrder_ID > 100;

Les conditions suivantes s'appliquent à la requête INSERT ... SELECT:

Il est bien sûr possible d'utiliser REPLACE à la place de INSERT pour remplacer les anciennes lignes.

INSERT DELAYED ...

L'option DELAYED de la commande INSERT est une option spécifique à MySQL très utile si vos clients ne peuvent pas attendre que INSERT se termine. C'est un problème fréquent quand on utilise MySQL pour des logs, mais aussi quand on utilise souvent des commandes SELECT ou UPDATE qui prennent beaucoup de temps. DELAYED a été ajouté à MySQL dans la version 3.22.15. C'est une extension de MySQL au ANSI SQL 92.

En utilisant INSERT DELAYED, le client re¸oit immédiatement un aquitement, et la ligne sera insérée quand la table ne sera plus utilisée par un autre thread.

Un autre avantage de INSERT DELAYED est que les insertions des clients sont regroupés, et écrits d'un seul bloc. C'est beaucoup plus rapide que de faire des insertions séparés.

Il y a quelques contraintes à l'utilisation de DELAYED :

Actuellement, les lignes en attente sont uniquement stockées en mémoire tant qu'elle ne sont pas insérées dans la table. Cela signifie que si on tue mysqld violemment, (kill -9) ou si mysqld meurt accidentellement, toutes les lignes en attente qui n'auront pas été écrites sur le disque seront perdues !

Les paragraphes suivants décrivent en détail ce qu'il se passe quand on utilise l'option DELAYED dans une requête INSERT ou REPLACE. Dans cette description, ``thread'' est un thread qui re¸oit une commande INSERT DELAYED ans ``handler'' est un thread qui gère toutes les opérations de INSERT DELAYED pour une table donnée.

Il faut noter que INSERT DELAYED est plus lent qu'un INSERT normal si la table n'est pas utilisée. L'utilisation d'un thread de gestion séparé pour chaque table sur lesquelles on utilise INSERT DELAYED rajoute également une surcharge au serveur. Ce qui signifie qu'il vaut mieux utiliser INSERT DELAYED uniquement quand c'est vraiment nécessaire!

MySQL supporte les syntaxes suivantes de JOIN pour une utilisation dans les SELECT :

reference_table, reference_table
reference_table [CROSS] JOIN reference_table
reference_table INNER JOIN reference_table condition_jointure
reference_table STRAIGHT_JOIN reference_table
reference_table LEFT [OUTER] JOIN reference_table condition_jointure
reference_table LEFT [OUTER] JOIN reference_table
reference_table NATURAL [LEFT [OUTER]] JOIN reference_table
{ OJ reference_table LEFT OUTER JOIN reference_table ON expr_conditionnelle }
reference_table RIGHT [OUTER] JOIN reference_table condition_jointure
reference_table RIGHT [OUTER] JOIN reference_table
reference_table NATURAL [RIGHT [OUTER]] JOIN reference_table

où reference_table est définie de la manière suivante :

nom_de_table [[AS] alias] [USE INDEX (liste_de_clefs)] [IGNORE INDEX (liste_de_clefs)]

et condition_jointure est définie comme suit :

ON expr_conditionnelle |
USING (column_list)

Généralement, vous ne devez avoir aucune condition, dans la partie ON, qui soit utilisée pour spécifier les lignes que vous voulez obtenir en résultat. (il y a des exceptions à cette règle). Si vous voulez restreindre les lignes résultantes, vous devez le faire dans la clause WHERE.

Notez que dans les versions antérieures à la 3.23.17, INNER JOIN ne prenait pas en compte condition_jointure !

La dernière syntaxe de LEFT OUTER JOIN vue plus haut, n'existe que pour assurer la compatibilité avec ODBC :

A partir de la version 3.23.12 de MySQL, vous pouvez donner des indications à propos de l'index à utiliser lors de la lecture d'informations d'une table. C'est utile si EXPLAIN montre que MySQL utilise un mauvais index de la liste de ceux disponibles. En spécifiant USE INDEX (liste_de_clefs), vous pouvez forcer MySQL à utiliser un index spécifique pour trouver les enregistrements dans la table. Une alternative réside dans l'utilisation de IGNORE INDEX (liste_de_clefs) pour dire à MySQL de ne pas utiliser certains index.

En MySQL 4.0.9, vous pouvez aussi utiliser la clause FORCE INDEX. Elle se comporte comme USE INDEX (key_list) mais en supposant que les scan de tables seront très coûteux. En d'autres termes, les scans de tables seront utilisés que s'il n'y a pas d'autres méthodes pour trouver les lignes.

USE/IGNORE KEY sont des synonymes de USE/IGNORE INDEX.

Note : USE INDEX, IGNORE INDEX et FORCE INDEX affectent uniquement les index qui sont utilisés lors du choix de la méthode de sélection des lignes dans la table, et comment faire une jointure. Elles n'affectent pas l'utilisation finale de l'index dans les clauses ORDER BY ou GROUP BY.

Quelques exemples :

mysql> SELECT * FROM table1,table2 WHERE table1.id=table2.id;
mysql> SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id;
mysql> SELECT * FROM table1 LEFT JOIN table2 USING (id);
mysql> SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id
    ->          LEFT JOIN table3 ON table2.id=table3.id;
mysql> SELECT * FROM table1 USE INDEX (key1,key2)
    ->          WHERE key1=1 AND key2=2 AND key3=3;
mysql> SELECT * FROM table1 IGNORE INDEX (key3)
    ->          WHERE key1=1 AND key2=2 AND key3=3;

See Section 7.2.9, « Comment MySQL optimise les clauses LEFT JOIN et RIGHT JOIN ».

SELECT ...
UNION [ALL | DISTINCT]
SELECT ...
  [UNION [ALL | DISTINCT]
   SELECT ...]

UNION est implémentée en MySQL 4.0.0.

UNION est utilisé pour combiner le résultat de plusieurs requêtes SELECT en un seul résultat.

Les colonnes listées dans la partie select_expression du SELECT doivent être du même type. Les noms de colonnes utilisés dans le premier SELECT seront utilisé comme nom de champs pour les résultats retournés.

Les commandes SELECT sont des sélections normales, mais avec les restrictions suivantes :

Si vous n'utilisez pas le mot clef ALL pour l'UNION, toutes les lignes retournées seront uniques, comme si vous aviez fait un DISTINCT pour l'ensemble du résultat. Si vous spécifiez ALL, vous aurez alors tout les résultats retournés par toutes les commandes SELECT.

Si vous voulez utiliser un ORDER BY pour le résultat final de UNION, vous devez utiliser des parenthèses :

(SELECT a FROM nom_de_table WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM nom_de_table WHERE a=11 AND B=2 ORDER BY a LIMIT 10)
ORDER BY a;

Note : vous ne pouvez pas mélanger les clauses UNION ALL et UNION DISTINCT dans la même requête. Si vous utilisez ALL dans une des UNION, alors elle devra être utilisée partout.

Les types et longueurs des colonnes du jeu de résultat de UNION prend en compte les valeurs lues dans tous les SELECT. Avant MySQL 4.1.1, une limitation de UNION est que seules les valeurs du premier SELECT étaient utilisée pour déterminer le type de résultats, et leur taille. Cela peut conduire à un raccourcissement de la valeur si, par exemple, le second SELECT trouvait des valeurs plus grandes que le premier SELECT :

mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
| a             |
| b             |
+---------------+

Cette limitation a été supprimée en MySQL version 4.1.1 :

mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
| a             |
| bbbbbbbbbb    |
+---------------+

Dans dans forme la plus simple, une sous-requête scalaire, par opposition à une sous-requête de ligne ou de table qui seront présentées plus loin, est un simple opérande. Vous pouvez l'utilisez à chaque fois qu'une valeur de colonne ou qu'une valeur littérale est valide, et vous pouvez en attendre les mêmes caractéristiques : type de données, taille et indication de nullité, etc. Par exemple :

CREATE TABLE t1 (s1 INT, s2 CHAR(5) NOT NULL);
SELECT (SELECT s2 FROM t1);

La sous-requête de la commande SELECT ci-dessus est de type CHAR, de longueur 5. Son jeu de caractères et sa collation sont ceux fournis par défaut, et elle porte une marque de nullité. En fait, toutes les sous-requêtes peuvent prendre la valeur NULL, car si la table est vide, la valeur de la sous-requête sera alors NULL. Il y a quelques restrictions :

Ainsi, lorsque vous lirez les exemples des sections suivantes qui utilisent la commande spartiate (SELECT column1 FROM t1), imaginez que votre code pourra contenir des commandes bien plus diverses et complexes.

Par exemple, supposons que nous avons ces deux tables :

CREATE TABLE t1 (s1 INT);
INSERT INTO t1 VALUES (1);
CREATE TABLE t2 (s1 INT);
INSERT INTO t2 VALUES (2);

Puis, que vous envoyons la commande suivante SELECT :

SELECT (SELECT s1 FROM t2) FROM t1;

Le résultat sera 2 car il y a une ligne dans t2, dont la colonne s1 a une valeur de 2.

La sous-requête peut faire partie d'une expression. Si c'est un opérande d'une fonction, n'oubliez pas les parenthèses.

Par exemple :

SELECT UPPER((SELECT s1 FROM t1)) FROM t2;

L'utilisation la plus répandue des sous-requêtes est celle-ci :

<non-subquery operand> <comparison operator> (<subquery>)

où <comparison operator> est l'un des opérateurs suivants :

= > < >= <= <>

Par exemple :

... 'a' = (SELECT column1 FROM t1)

Il fut un temps où la seule place possible pour une sous-requête était à la droite de l'opérateur de comparaison, mais vous pourrez rencontrer de vieilles bases qui insisteront sur ce point.

Voici un exemple de comparaison classiques, pour lequel vous ne pouvez pas utiliser de jointure : trouvez toutes les valeurs de la table t1 qui sont égales au maximum de la valeur dans la table t2.

SELECT column1 FROM t1
       WHERE column1 = (SELECT MAX(column2) FROM t2);

Voici un autre exemple, qui est aussi impossible à réaliser avec une jointure, car elle impose l'agrégation de plusieurs tables : trouver toutes les lignes de la table t1 qui contiennent une valeur qui apparaît deux fois.

SELECT * FROM t1
       WHERE 2 = (SELECT COUNT(column1) FROM t1);

Syntaxe :

<operand> <comparison operator> ANY (<subquery>)
<operand> IN (<subquery>)
<operand> <comparison operator> SOME (<subquery>)

Le mot ANY, qui doit suivre immédiatement un opérateur de comparaison, signifie : ``retourne TRUE si la comparaison est TRUE pour UNE des lignes que la sous-requête retourne.'' Par exemple :

SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2);

Supposons qu'il y ait une ligne dans la table t1 qui contienne {10}. L'expression est TRUE si la table t2 contient {21,14,7} car il y a une valeur de t2, 7, qui est inférieure à 10. Cette expression est FALSE si la table t2 contient {20,10}, ou si la table t2 est vide. L'expression est UNKNOWN si la table t2 contient {NULL,NULL,NULL}.

Le mot IN est un alias de = ANY. Les deux commandes suivantes sont identiques :

SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 IN    (SELECT s1 FROM t2);

Le mot SOME est un alias de ANY. Les deux commandes suivantes sont identiques :

SELECT s1 FROM t1 WHERE s1 <> ANY  (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 <> SOME (SELECT s1 FROM t2);

L'utilisation du mot SOME est rare, mais les exemples ci-dessus montrent pourquoi il peut être utile. En langage parlé, ``a n'est pas égal à aucun b'' signifie pour la majorité des gens, ``il n'y a pas de b qui est égal à a'' : ce n'est pas la signification de la syntaxe SQL. En utilisant <> SOME, vous pouvez vous assurer que tout le monde comprend le véritable sens de la commande.

Syntaxe :

<operand> <comparison operator> ALL (<subquery>)

Le mot ALL, qui doit suivre immédiatement l'opérateur de comparaison, signifie ``retourne TRUE si la comparaison est TRUE pour TOUTES les lignes que la sous-requête retourne''.

Par exemple :

SELECT s1 FROM t1 WHERE s1 > ALL (SELECT s1 FROM t2);

Supposons qu'il y ait une ligne dans la table t1 contenant {10}. L'expression est TRUE si la table t2 contient {-5,0,+5} car les trois valeurs de t2 sont inférieures à 10. L'expression est FALSE si la table t2 contient {12,6,NULL,-100} car il y a une des valeurs de la table t2, ici 12, qui est plus grande que 10. L'expression est UNKNOWN si la table t2 contient {0,NULL,1}.

Finalement, si la table t2 est vide, le résultat est TRUE. Vous pouvez pensez que le résultat doit être indéterminé (UNKNOWN), mais c'est bien TRUE. Ce qui fait que, bizarrement,

SELECT * FROM t1 WHERE 1 > ALL (SELECT s1 FROM t2);

est TRUE si la table t2 est vide, mais

SELECT * FROM t1 WHERE 1 > (SELECT s1 FROM t2);

est UNKNOWN si la table t2 est vide. De plus,

SELECT * FROM t1 WHERE 1 > ALL (SELECT MAX(s1) FROM t2);

est UNKNOWN si la table t2 est vide. En général, les tables avec des NULL et les tables vides sont des cas particuliers : lorsque vous écrivez vos sous-requêtes, pensez bien à les prendre en compte.

Jusqu'ici, nous avons étudié les sous-requêtes scalaires, ou de colonnes : des sous-requêtes qui retournent une seule valeur dans une ligne. Une sous-requête de ligne est une variante qui retourne une seule ligne : elle peut donc retourner plusieurs colonnes. Voici deux exemples :

SELECT * FROM t1 WHERE (1,2) = (SELECT column1, column2 FROM t2);
SELECT * FROM t1 WHERE ROW(1,2) = (SELECT column1, column2 FROM t2);

Les requêtes ci-dessus sont toutes les deux TRUE si la table t2 a une ligne où column1 = 1 et column2 = 2.

L'expression (1,2) est parfois appelée un constructeur de ligne et est valide dans d'autres contextes. Par exemple, les deux commandes suivantes sont sémantiquement équivalentes, même si la précédente peut être optimisée :

SELECT * FROM t1 WHERE (column1,column2) = (1,1);
SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;

L'utilisation traditionnelle des constructeurs de ligne est lors des comparaisons avec des sous-requêtes qui retournent plusieurs colonnes. Par exemple, cette requête répond à la question : ``trouve toutes les lignes de la table t1 qui sont dupliquées dans la table t2'':

SELECT column1,column2,column3
       FROM t1
       WHERE (column1,column2,column3) IN
             (SELECT column1,column2,column3 FROM t2);

Si une sous-requête retourne absolument aucune valeur, alors la clause EXISTS <subquery> est TRUE, et la clause NOT EXISTS <subquery> est FALSE. Par exemple :

SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);

Traditionnellement, une sous-requête qui EXISTS commence avec SELECT * mais elle peut commencer aussi bien avec SELECT 5 ou SELECT column1 ou n'importe quoi d'autre encore : MySQL ignore la liste de colonnes du SELECT de cette requête, ce qui fait que cela n'a pas d'importance.

Dans l'exemple ci-dessus, si la table t2 ne contient aucune ligne, même pas de ligne avec uniquement des valeurs NULL, alors la condition EXISTS est TRUE. C'est un exemple plutôt exceptionnel, car il y a presque toujours une sous-requête [NOT] EXISTS qui contiendra des corrélations. Voici des exemples plus concrets :

Le dernier exemple est une double imbrication de requête NOT EXISTS : elle possède une clause NOT EXISTS à l'intérieur de la clause NOT EXISTS. Formellement, elle répond à la question : ``Existe-t-il une ville avec un magasin qui n'est pas dans Stores?''. Mais il est plus facile de dire qu'une clause NOT EXISTS imbriquée répond à la question ``est-ce que x est vrai pour tous les y?''.

Une sous-requête corrélée est une sous-requête qui contient une référence à une colonne qui est aussi dans une requête différente.

Par exemple :

SELECT * FROM t1 WHERE column1 = ANY
       (SELECT column1 FROM t2 WHERE t2.column2 = t1.column2);

Notez que dans notre exemple, la sous-requête contient une référence à une colonne de la table t1, même si la sous-requête de la clause FROM ne mentionne pas la table t1. MySQL recherche hors de la requête et trouve t1 dans la requête externe.

Supposez que la table t1 contienne une ligne où column1 = 5 et column2 = 6; alors que la table t2 continue une ligne où column1 = 5 et column2 = 7. l'expression ... WHERE column1 = ANY (SELECT column1 FROM t2) sera alors TRUE, mais dans cet exemple, la clause WHERE de la sous-requête est FALSE (car 7 <> 5), et donc, toute la sous-requête est FALSE.

Règles de contexte : MySQL fait les évaluations de l'intérieur vers l'extérieur. Par exemple :

SELECT column1 FROM t1 AS x
  WHERE x.column1 = (SELECT column1 FROM t2 AS x
    WHERE x.column1 = (SELECT column1 FROM t3 WHERE x.column2 = t3.column1));

Dans l'exemple ci-dessus, x.column2 doit être une colonne de la table t2 car SELECT column1 FROM t2 AS x ... prend le nom de t2. ce n'est pas une colonne de la table t1 car SELECT column1 FROM t1 ... est une requête externe, qui est à venir.

Pour les sous-requêtes placées dans des clauses HAVING ou ORDER BY, MySQL recherche aussi les noms de colonnes dans la liste des sélections externes.

Dans certains cas, les sous-requêtes corrélées sont optimisées. Par exemple :

val IN (SELECT key_val FROM tbl_name WHERE correlated_condition)

Sinon, elles sont inefficaces et plutôt lentes. Réécrire une requête sous forme de jointure peut améliorer les performances.

Les sous-requêtes sont valides dans la clause FROM d'une commande SELECT. Voici une syntaxe que vous allez rencontrer :

SELECT ... FROM (<subquery>) AS <name> ...

La clause AS <name> est obligatoire, car les tables de la clause FROM doivent avoir un nom. Toutes les colonnes de la sous-requête <subquery> doivent avoir des noms distincts. Vous pourrez trouver cette syntaxe décrite ailleurs dans ce manuel, sous le nom de ``tables dérivées''.

Par exemple, supposons que vous avons cette table :

CREATE TABLE t1 (s1 INT, s2 CHAR(5), s3 FLOAT);

Comment utiliser la fonctionnalité de sous-requêtes dans la clause FROM, avec cette table d'exemple :

INSERT INTO t1 VALUES (1,'1',1.0);
INSERT INTO t1 VALUES (2,'2',2.0);
SELECT sb1,sb2,sb3
       FROM (SELECT s1 AS sb1, s2 AS sb2, s3*2 AS sb3 FROM t1) AS sb
       WHERE sb1 > 1;

Résultat : 2, '2', 4.0.

Voici un autre exemple : supposons que vous voulez connaître la moyenne de la somme pour un groupe de table. Ceci ne fonctionnera pas :

SELECT AVG(SUM(column1)) FROM t1 GROUP BY column1;

Mais cette requête-ci vous donnera les informations nécessaires :

SELECT AVG(sum_column1)
       FROM (SELECT SUM(column1) AS sum_column1
             FROM t1 GROUP BY column1) AS t1;

Notez que les colonnes sont nommées à partir de la sous-requête : (sum_column1) est reconnue dans la requête externe.

Actuellement, les sous-requêtes en clause FROM ne peuvent pas être corrélées.

Il y a de nouvelles erreurs qui ne s'appliquent qu'aux sous-requêtes. Cette section les rassemble, car elles vous aideront à garder en tête certains points importants.

Il est valide d'utiliser une sous-requête lors d'une affectation dans une commande UPDATE, car les sous-requêtes sont valides avec les commandes UPDATE et DELETE, tout comme dans les commandes SELECT. Cependant, vous ne pouvez pas les utiliser sur la même table, qui est ici t1, car cette table est alors la cible de la clause FROM et de la commande UPDATE.

Généralement, l'échec d'un sous-requête entraîne l'échec de toute la commande.

Le développement des sous-requêtes se poursuit, et aucun des conseils d'optimisation ne sera valable longtemps. Voici quelques astuces que vous voulez prendre en compte :

Le truc ci-dessus peut accélérer certains programmes, et en ralentir d'autres. En utilisant la fonction utilitaire BENCHMARK(), vous pouvez obtenir une idée de votre cas. Ne vous attardez pas trop à transformer vos jointures, sauf si la compatibilité avec les anciennes versions est importante pour vous.

Quelques optimisation que MySQL va prendre en charge lui-même :

Il y a un chapitre intitulé ``Comment MySQL adapte les sous-requêtes'' dans les manuels internes de MySQL, que vous pouvez trouver en téléchargeant les sources de MySQL : il est dans un fichier appelé internals.texi, dans le dossier Docs.

Jusqu'à la version 4.1, seules les requêtes imbriquées de la forme INSERT ... SELECT ... et REPLACE ... SELECT ... étaient supportées.

La clause IN() peut être utilisée dans certains contextes, pour tester la présence de valeur dans un ensemble de données.

Il est souvent possible de réécrire une requête sans sous-requête :

SELECT * FROM t1 WHERE id IN (SELECT id FROM t2);

Cela peut se réécrire :

SELECT t1.* FROM t1,t2 WHERE t1.id=t2.id;

Les requêtes :

SELECT * FROM t1 WHERE id NOT IN (SELECT id FROM t2);
SELECT * FROM t1 WHERE NOT EXISTS (SELECT id FROM t2 WHERE t1.id=t2.id);

peuvent être réécrites :

SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
                                       WHERE table2.id IS NULL;

Une clause LEFT [OUTER] JOIN peut être plus rapide qu'une sous-requête équivalent, car le serveur va pouvoir l'optimiser bien mieux : c'est un fait qui n'est pas spécifique à MySQL. Avant SQL-92, les jointures externes n'existaient pas, et les sous-requêtes étaient la seule méthode pour résoudre certains problèmes. Aujourd'hui, le serveur MySQL et d'autres bases de données modernes offrent toute une gamme de jointures externes.

Pour les sous-requêtes plus complexes, vous pouvez simplement créer des tables temporaires pour contenir les résultats intermédiaires. Dans certains cas, cela ne sera pas possible. C'est notamment le cas des commandes de type DELETE, pour lesquelles le standard SQL ne supporte pas les jointures, sauf pour les sous-requêtes. Dans ces situations, trois solutions s'offrent à vous :

MySQL 4.0 supporte les commandes DELETE multi-tables qui peuvent être utilisées pour effacer des lignes dans une table en fonction d'informations qui sont dans une autre table, ou même effacer des lignes simultanément dans plusieurs tables. Les commandes UPDATE multi-tables sont aussi supportés depuis la version 4.0.

Dans certains cas, MySQL change automatiquement la spécification d'une colonne fournie dans la commande CREATE TABLE. (Cela peut aussi arriver avec ALTER TABLE) :

Si vous voulez voir si MySQL a utilisé un autre type que celui que vous avez spécifié, utilisez la commande DESCRIBE nom_de_table, après votre création ou modification de structure de table.

Certain types de colonnes peuvent être modifiés si vous compressez une table en utilisant l'utilitaire myisampack. See Section 14.1.3.3, « Caractéristiques des tables compressées ».

CREATE USER user [IDENTIFIED BY [PASSWORD] 'password']
    [, user [IDENTIFIED BY [PASSWORD] 'password']] ...

La commande CREATE USER crée un nouveau compte MySQL. Pour l'utiliser, vous devez avoir les droits de CREATE USER ou les droits d'INSERT dans la table de droits de la base mysql. Pour chaque compte, CREATE USER crée un nouvel enregistrement dans la table mysql.user, sans aucun droit. Une erreur survient si le compte existe déjà. Le compte peut recevoir un mot de passe avec la clause optionnelle IDENTIFIED BY. La valeur user et le mot de passe sont données de la même manière que dans la commande GRANT.

La commande CREATE USER a été ajoutée en MySQL 5.0.2.

DROP USER user_name

Cette commande a été ajoutée en MySQL 4.1.1.

Elle efface un utilisateur qui n'a aucun droits.

Pour effacer un utilisateur dans MySQL, vous devriez utiliser l'une des procédures suivantes, dans cet ordre :

Si vous utilisez une vieille version de MySQL, vous devriez commencer par effacer les droits, puis l'utilisateur avec :

DELETE FROM mysql.user WHERE user='username' and host='hostname';
FLUSH PRIVILEGES;

GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ...
    ON {tbl_name | * | *.* | db_name.*}
    TO user [IDENTIFIED BY [PASSWORD] 'password']
        [, user [IDENTIFIED BY [PASSWORD] 'password']] ...
    [REQUIRE
        NONE |
        [{SSL| X509}]
        [CIPHER cipher [AND]]
        [ISSUER issuer [AND]]
        [SUBJECT subject]]
    [WITH [GRANT OPTION | MAX_QUERIES_PER_HOUR count |
                          MAX_UPDATES_PER_HOUR count |
                          MAX_CONNECTIONS_PER_HOUR count]]

REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ...
    ON {tbl_name | * | *.* | db_name.*}
    FROM user [, user] ...

REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ...

Les commandes GRANT et REVOKE permettent à l'administrateur système de créer et supprimer des comptes utilisateur et de leur donner ou retirer des droits. GRANT et REVOKE sont implémentées en MySQL 3.22.11 ou plus récent. Pour les anciennes versions de MySQL, ces commandes ne font rien.

Les informations sur les comptes MySQL sont stockés dans la base mysql. Cette base et son accès sont présentés en détails dans la section Chapitre 5, Administration du serveur.

Les droits sont donnés à 4 niveaux :

Pour faciliter la suppression de tous les droits d'un utilisateur, MySQL 4.1.2 a ajouté la syntaxe suivante, qui efface tous les droits de base, table et colonne pour un utilisateur donné :

REVOKE ALL PRIVILEGES,GRANT FROM user_name [, user_name ...]

Avant MySQL 4.1.2, tous les droits ne peuvent pas être effacés d'un coup. Il faut deux commandes pour cela :

REVOKE ALL PRIVILEGES FROM user [, user] ...
REVOKE GRANT OPTION FROM user [, user] ...

Pour les commandes GRANT et REVOKE, la clause priv_type peut être spécifiée par les constantes suivantes :

USAGE peut être utilisé lorsque vous voulez créer un utilisateur sans aucun droit.

Les droits de CREATE TEMPORARY TABLES, EXECUTE, LOCK TABLES, REPLICATION ..., SHOW DATABASES et SUPER sont nouveaux en version 4.0.2. Pour utiliser ces droits après mise à jour en 4.0.2, vous devez exécuter le script mysql_fix_privilege_tables. See Section 2.6.7, « Mise à jour des tables de droits ».

Dans les anciennes versions de MySQL, le droit de PROCESS donnait les mêmes droits que le nouveau droit SUPER.

Vous pouvez donner des droits globaux en utilisant la syntaxe ON *.*. Vous pouvez donner des droits de base en utilisant la syntaxe ON nom_base.*. Si vous spécifiez ON * et que vous avez une base de données qui est déjà sélectionnée, vous allez donner des droits pour la base de données courante. Attention : si vous spécifiez ON * et que vous n'avez pas de base courante, vous allez affecter les droits au niveau du serveur !

Les droits EXECUTION, FILE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN et SUPER sont des droits d'administration, qui ne peuvent être donnés que globalement (avec la syntaxe ON *.*).

Les autres droits peuvent être donnés globalement ou à des niveaux plus spécifiques.

Les seuls droits priv_type que vous pouvez donner au niveau d'une table sont SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT OPTION, INDEX et ALTER.

Les seuls droits priv_type que vous pouvez donner au niveau d'une colonne (avec la clause column_list) sont SELECT, INSERT et UPDATE.

GRANT ALL assigne des droits que vous possédez au niveau où vous le possédez. Par exemple, si vous utilisez GRANT ALL ON db_name.*, qui est un droit de niveau de base de données, aucun des droits globaux, comme FILE ne sera donné.

MySQL vous permet de donner des droits au niveau d'une base de données, même si la base de données n'existe pas, pour vous aider à préparer l'utilisation de la base de données. Actuellement, MySQL ne vous permet pas de créer des droits pour une table si la table n'existe pas.

MySQL ne supprime pas les droits lorsqu'un utilisateur efface une table ou une base.

Notez bien : les caractères joker ‘_’ et ‘%’ sont autorisés lors de la spécification de noms dans la commande GRANT. Cela signifie que si vous voulez utiliser par exemple le caractère littéral ‘_’ comme nom de base, vous devez le spécifier sous la forme ‘\_’ dans la commande GRANT, pour éviter à l'utilisateur d'accéder à d'autres bases, dont le nom pourrait correspondre au masque d'expression régulière ainsi créé. Utilisez plutôt GRANT ... ON `foo\_bar`.* TO ....

Afin de permettre l'identification des utilisateurs depuis des hôtes arbitraires, MySQL supporte la spécification du nom d'utilisateur nom_utilisateur sous la forme user@host. Si vous voulez spécifier un nom d'utilisateur user qui contient des caractères spéciaux tels que ‘-’, ou une chaîne d'hôte host qui contient des caractères joker (comme ‘%’), vous pouvez placer le nom de l'utilisateur ou de l'hôte entre guillemets (par exemple, 'test-utilisateur'@'test-nomdhote').

Vous pouvez spécifier des caractères jokers dans le nom d'hôte. Par exemple, user@'%.loc.gov' fait correspondre l'utilisateur user de n'importe quel hôte du domaine loc.gov, et user@'144.155.166.%' fait correspondre l'utilisateur user à n'importe quelle adresse de la classe C 144.155.166.

La forme simple de user est synonyme de user@"%".

MySQL ne supporte pas de caractères joker dans les noms d'utilisateur. Les utilisateurs anonymes sont définis par l'insertion de ligne avec User='' dans la table mysql.user, ou en créant un utilisateur avec un nom vide, grâce à la commande GRANT.

mysql> GRANT ALL ON test.* TO ''@'localhost' ...

Attention : si vous autorisez des utilisateurs anonymes à se connecter à votre serveur, vous devriez aussi donner ces droits à tous les utilisateurs locaux user@localhost car sinon, la ligne dans la table mysql.user sera utilisée lorsque l'utilisateur se connectera au serveur MySQL depuis la machine locale ! (Ce compte est créé durant l'installation de MySQL.)

Vous pouvez vérifier si cela s'applique à vous en exécutant la requête suivante :

mysql> SELECT Host,User FROM mysql.user WHERE User='';

Si vous voulez effacer les utilisateurs anonymes d'un serveur, utilisez ces commandes :

mysql> DELETE FROM mysql.user WHERE Host='localhost' AND User='';
mysql> FLUSH PRIVILEGES;

Actuellement, la commande GRANT supporte uniquement les noms d'hôte, colonne, table et bases de données d'au plus 60 caractères. Un nom d'utilisateur peut être d'au plus 16 caractères.

Les droits pour les tables et colonnes sont combinés par OU logique, avec les quatre niveaux de droits. Par exemple, si la table mysql.user spécifie qu'un utilisateur a un droit global de SELECT, ce droit ne pourra pas être annulé au niveau base, table ou colonne.

Les droits d'une colonne sont calculés comme ceci :

droit global
OR (droit de base de données ET droit d'hôte)
OR droit de table
OR droit de colonne

Dans la plupart des cas, vous donnez des droits à un utilisateur en utilisant un seul des niveaux de droits ci-dessus, ce qui fait que la vie n'est pas aussi compliquée. Le détails de la procédure de vérification des droits et disponible dans Section 5.5, « Règles de sécurité et droits d'accès au serveur MySQL ».

Si vous donnez des droits à une paire utilisateur/hôte qui n'existe pas dans la table mysql.user, une ligne sera créée et restera disponible jusqu'à son effacement avec la commande DELETE. En d'autre termes, GRANT crée une ligne dans la table user, mais REVOKE ne la supprime pas. Vous devez le faire explicitement avec la commande DELETE.

Avec MySQL version 3.22.12 ou plus récent, si un nouvel utilisateur est créé, ou si vous avez les droits de GRANT globaux, le mot de passe sera configuré avec le mot de passe spécifié avec la clause IDENTIFIED BY, si elle est fournie. Si l'utilisateur a déjà un mot de passe, il sera remplacé par ce nouveau.

Attention : si vous créez un nouvel utilisateur, mais ne spécifiez pas de clause IDENTIFIED BY, l'utilisateur n'aura pas de mot de passe. Ce n'est pas sécuritaire.

Les mots de passe peuvent aussi être modifiés avec la commande SET PASSWORD. See Section 13.5.1.5, « Syntaxe de SET PASSWORD ».

Si vous ne voulez pas transmettre le mot de passe en texte clair, vous pouvez immédiatement utiliser l'option PASSWORD suivi du mot de passe déjà chiffré avec la fonction PASSWORD() ou l'API C make_scrambled_password(char *to, const char *password).

Si vous donnez les droits de base, une ligne sera ajoutée dans la table mysql.db. Lorsque les droits sur cette base seront supprimés avec la commande REVOKE, cette ligne disparaîtra.

Si un utilisateur n'a pas de droit sur une table, elle ne sera pas affichée lorsqu'il demandera la liste des tables avec la commande SHOW TABLES. Si un utilisateur n'a pas de droit dans une base, le nom de la base ne sera pas affiché par SHOW DATABASES à moins que l'utilisateur n'ai un droit de SHOW DATABASES.

La clause WITH GRANT OPTION donne à l'utilisateur le droit de donner les droits qu'il possède à d'autres utilisateurs. La plus grande prudence est recommandée pour cette commande, car il permettra à terme à deux utilisateurs de combiner les droits dont ils disposent.

Vous ne pouvez pas donner un droit que vous ne possédez pas. le droit de GRANT OPTION ne vous donne le droit que de donner les droits que vous possédez.

Sachez que si vous donnez à quelqu'un le droit de GRANT OPTION, tous les droits que possède cet utilisateur seront distribuables. Supposez que vous donnez à un utilisateur le droit d'INSERT dans une base de données. Si vous donnez le droit de SELECT sur une base, et spécifiez l'option WITH GRANT OPTION, l'utilisateur peut distribuer non seulement son droit de SELECT, mais aussi son droit de INSERT. Si vous donnez ensuite le droit de UPDATE, il pourra alors distribuer INSERT, SELECT et UPDATE.

Il est recommandé de ne pas donner de droits de ALTER à un utilisateur normal. Si vous le faîtes, l'utilisateur pourra essayer de contourner le système de droits en renommant des tables.

MAX_QUERIES_PER_HOUR #, MAX_UPDATES_PER_HOUR # et MAX_CONNECTIONS_PER_HOUR # sont nouveaux en MySQL 4.0.2. Ces deux options limitent le nombre de requêtes et de modifications qu'un utilisateur peut réclamer dans une heure. Si # vaut 0 (valeur par défaut), alors cela signifie qu'il n'y a pas de limitations pour cet utilisateur. See Section 5.6.4, « Limiter les ressources utilisateurs ». Note: pour spécifier l'une de ces options pour un utilisateur existant sans ajouter d'autres privilèges additionnels, utilisez GRANT USAGE ... WITH MAX_....

MySQL peut vérifier les attributs X509 en plus des éléments d'identifications habituels, comme le nom d'utilisateur et le mot de passe. Pour spécifier des options SSL pour un compte MySQL, utilisez la clause REQUIRE de la commande GRANT. Pour des informations générales sur SSL et MySQL, voyez Section 5.6.7, « Utilisation des connexions sécurisées ».

Il y a différentes possibilités pour limiter le type de connexions d'un compte :

Les clauses SUBJECT, ISSUER et CIPHER peuvent être combinées avec la clause REQUIRE comme ceci :

mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
    -> IDENTIFIED BY 'goodsecret'
    -> REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
       O=MySQL demo client certificate/
       CN=Tonu Samuel/Email=tonu@example.com'
    -> AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
       O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com'
    -> AND CIPHER 'EDH-RSA-DES-CBC3-SHA';

Notez que les valeurs de SUBJECT et ISSUER doivent être saisies comme une seule chaîne.

Depuis MySQL 4.0.4, le mot clé AND est optionnel entre les clauses de REQUIRE.

L'ordre des options est libre, mais les options doivent être spécifiées une seule fois.

Notez que si vous utilisez des droits de niveau table ou colonne même pour un utilisateur, le serveur vérifiera alors ces droits pour tous les utilisateurs, et cela ralentira MySQL un peu.

Lorsque mysqld démarre, tous les droits sont stockés en mémoire. Les droits de bases, tables et colonnes prennent aussitôt effet, et les droits des utilisateurs prendront effet dès leur prochaine configuration. Les modifications sur les tables de droits que vous effectuez avec les commandes GRANT et REVOKE sont prises en compte immédiatement par le serveur. Si vous modifiez manuellement les tables (avec INSERT, UPDATE, etc...), vous devez exécuter la commande FLUSH PRIVILEGES, ou la commande en ligne mysqladmin flush-privileges pour indiquer au serveur qu'il doit recharger les droits. See Section 5.5.7, « Quand les modifications de privilèges prennent-ils effets ? ».

Les différences notables entre l'ANSI SQL et MySQL pour la commande GRANT sont :

RENAME USER old_user TO new_user
    [, old_user TO new_user] ...

La commande RENAME USER renomme un compte MySQL existant. Pour l'utiliser, vous devez avoir les droits globaux de CREATE USER ou les droits de UPDATE dans la base mysql. Une erreur survient si l'ancien compte n'existe pas, ou que le nouveau compte existe déjà. Les valeurs old_user et new_user sont données de la même fa¸on que dans la commande GRANT.

La commande RENAME USER a été ajoutée en MySQL 5.0.2.

SET PASSWORD = PASSWORD('some password')
SET PASSWORD FOR user = PASSWORD('some password')

La commande SET PASSWORD assigne un mot de passe à un compte utilisateur existant.

La première syntaxe modifie le mot de passe de l'utilisateur courant. Tout client qui s'est connecté avec un compte non-anonyme peut changer le mot de passe pour ce compte.

La seconde syntaxe modifie le mot de passe pour un compte tiers, sur le serveur. Seuls les clients qui ont accès aux bases mysql peuvent faire cela. La valeur de user doit être donnée au format user_name@host_name, où user_name et host_name sont tels que listés dans les colonnes User et Host de la table mysql.user. Par exemple, si vous avez une ligne avec les champs User et Host qui valent 'bob' et '%.loc.gov', vous pouvez écrire la commande suivante :

mysql> SET PASSWORD FOR 'bob'@'%.loc.gov' = PASSWORD('newpass');

C'est l'équivalent de la commande suivante :

mysql> UPDATE mysql.user SET Password=PASSWORD('newpass')
    -> WHERE User='bob' AND Host='%.loc.gov';
mysql> FLUSH PRIVILEGES;

ANALYZE TABLE nom_de_table[,nom_de_table...]

Cette commande analyse et stocke la clé de distribution de la table. Durant l'analyse, la table est verrouillée en lecture. Cette commande fonctionne avec les tables MyISAM et BDB.

C'est l'équivalent de la commande en ligne myisamchk -a.

MySQL utilise les clés de distribution pour décider dans quel ordre les tables doivent être rassemblées lors des jointures qui ne s'effectuent pas sur une constante.

La commande retourne une table avec les colonnes suivantes :

Vous pouvez vérifier la clé de distribution stockée avec la commande SHOW INDEX. See Section 13.5.3.6, « Syntaxe de SHOW DATABASES ».

Si la table n'a pas changé depuis la dernière commande ANALYZE TABLE, elle ne sera pas analysée à nouveau.

BACKUP TABLE nom_de_table[,nom_de_table...] TO '/chemin/vers/le/dossier/de/sauvegardes'

Note : cette commande est obsolète. Nous travaillons à une solution de remplacement améliorée, qui proposera des sauvegardes à chaud. Durant ce temps, le script mysqlhotcopy peut être utilisé.

Cette commande copie le nombre minimal de fichiers de table dont en a besoin pour la restaurer vers le dossier de sauvegardes après avoir rafraîchit les changements dans le disque. Cela ne fonctionne actuellement que pour les tables au format MyISAM. Pour les tables MyISAM, elle ne copie que les fichiers .frm (définition) et .MYD (données), le fichier d'index .MYD pouvant, lui, être reconstruit à partir des deux autres.

Avant d'utiliser cette commande, merci de lire Section 5.7.1, « Sauvegardes de base de données ».

Pendant la sauvegarde, un verrou de lecture est posé sur chaque table, une par une, lors de leur copie. Si vous voulez sauvegarder une image instantanée de plusieurs table, vous devez d'abord exécuter un LOCK TABLES obtenant un verrou de lecture pour chaque table concernée.

La commande retourne une table avec les colonnes suivantes :

Notez que BACKUP TABLE n'est disponible en MySQL que depuis la version 3.23.25.

CHECK TABLE tbl_name[,tbl_name...] [option [option...]]

option = QUICK | FAST | MEDIUM | EXTENDED | CHANGED

CHECK TABLE ne fonctionne qu'avec les tables MyISAM et InnoDB. Avec les tables MyISAM, c'est l'équivalent de la commande myisamchk -m table_name sur la table.

Par défaut, l'option MEDIUM est utilisée.

Cette commande vérifie l'intégrité des tables. Pour les tables MyISAM, des statistiques importantes sont mises à jour. La commande retourne les informations suivantes sur la table dans les colonnes suivantes :

Notez que vous pouvez obtenir de nombreuses lignes d'informations pour chaque table. La dernière ligne sera du type Msg_type status et doit être normalement OK. Si vous n'obtenez pas de statut OK ou Not checked, il vous faudra exécuter une réparation de la table. See Section 5.7.3, « Utilisation de myisamchk pour la maintenance des tables et leur recouvrement ». Not checked signifie que la table a indiqué qu'il n'y a pas de vérification à faire.

Les différents types de vérifications sont les suivants :

Pour les tables à format de dynamique de type MyISAM, une vérification de table sera toujours démarrée avec une option de niveau MEDIUM. Pour les tables à format de ligne statique, nous évitons les niveaux de QUICK et FAST car les lignes sont rarement corrompues.

Vous pouvez combiner les options de vérification comme ceci :

CHECK TABLE test_table FAST QUICK;

L'exemple ci-dessus va simplement faire une vérification de la table, pour s'assurer qu'elle a été correctement fermée.

Note : dans certains cas, CHECK TABLE va modifier la table! Cela arrive si la table a été marquée comme "corrupted" et "not closed properly" mais CHECK TABLE n'a trouvé aucun problème dans la table. Dans ce cas, CHECK TABLE va marquer la table comme correcte.

Si une table est corrompue, il est probable que les problèmes sont dans les fichiers d'index et non pas dans les données. Tous les types de vérifications présentés ci-dessus vérifient les index soigneusement, et ils devraient trouver la plupart des erreurs.

Si vous voulez simplement vérifier une table que vous supposez correcte, vous pouvez n'utiliser aucune option, ou l'option QUICK. Cette dernière peut aussi être utilisée si vous êtes pressé, et que vous pouvez prendre le risque minime que QUICK ne trouve pas d'erreur dans votre fichier. Dans la plupart des cas, MySQL doit trouver toutes les erreurs de données, pour un usage normal. Si cela arrive, alors la table est marquée comme 'corrupted', auquel cas, la table ne pourra pas être utilisée tant qu'elle n'a pas été réparée).

FAST et CHANGED sont surtout destinées à être utilisées depuis un script : par exemple, il peut être exécuté depuis une tâche cron, si vous voulez vérifier la table de temps en temps. Dans la plupart des cas, l'option FAST doit être préférée à CHANGED : le seul cas ou vous pourriez préférez CHANGED est lorsque vous soup¸onnez avoir trouvé un bogue dans les tables MyISAM.

EXTENDED ne doit être utilisé qu'après une vérification normale, et que vous obtenez toujours des erreurs étranges lorsque MySQL essaie de modifier une ligne ou trouve une ligne avec clé (ce qui est très rare, si une vérification a réussie).

Certains problèmes rapportés par la commande CHECK TABLE, ne peuvent être corrigés automatiquement :

CHECKSUM TABLE tbl_name[,tbl_name ...] [ QUICK | EXTENDED ]

Calcule la somme de contrôle de la table.

Si QUICK est spécifié, la somme de contrôle instantanée est retournée, ou NULL si la table ne supporte pas les sommes de contrôle instantanées. See Section 13.2.5, « Syntaxe de CREATE TABLE ».

En mode EXTENDED, toute la table est lue, ligne par ligne, et la somme de contrôle est calculée. Cela peut être très lent pour les tables de grande taille.

Par défaut, sans QUICK ni EXTENDED, MySQL retourne la somme de contrôle si la table le supporte, et sinon, scanne la table.

Cette commande a été ajoutée en MySQL 4.1.1.

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

OPTIMIZE TABLE doit être utilisée si une grande partie de la base a été effacée, ou si vous avez fait de nombreuses modifications dans une table à format de ligne dynamique (des tables qui ont des colonnes de type VARCHAR, BLOB et TEXT). Les lignes effacées sont conservées dans une liste, et les prochaines opérations d'INSERT réutilisent les vieilles positions de lignes. Vous pouvez vous servir de la commande OPTIMIZE TABLE pour récupérer l'espace utilisé et défragmenter le fichier de données.

Dans la plupart des installations, vous n'avez pas à utiliser OPTIMIZE TABLE. Même si vous faites beaucoup de mises à jour sur des colonnes à taille dynamique, il n'est pas évident que vous ayez à passer cette commande plus d'une fois par semaine ou par mois, et uniquement sur quelques tables.

Pour le moment, OPTIMIZE TABLE fonctionne uniquement avec les tables de type MyISAM et BDB. Pour les tables BDB, OPTIMIZE TABLE est actuellement l'équivalent de ANALYZE TABLE. See Section 13.5.2.1, « Syntaxe de ANALYZE TABLE ».

Vous pouvez vous arranger pour que OPTIMIZE TABLE fonctionne sur d'autres types de tables, en démarrant mysqld avec --skip-new ou --safe-mode, mais dans ce cas, OPTIMIZE TABLE est simplement l'équivalent de ALTER TABLE.

OPTIMIZE TABLE fonctionne comme ceci :

Notez que la table est verrouillée durant la commande OPTIMIZE TABLE.

Avant MySQL 4.1.1, OPTIMIZE n'était pas reportée dans le log binaire. Depuis MySQL 4.1.1 elles le sont, à moins que l'attribut optionnel NO_WRITE_TO_BINLOG ou son alias LOCAL ne soit utilisé.

REPAIR TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE répare une table possiblement corrompue. Par défaut, elle a le même effet que myisamchk --recover tbl_name sur une table. REPAIR TABLE fonctionne unqiuement avec les tables MyISAM.

Normalement, vous n'avez pas à exécuter cette commande, mais si une catastrophe vous frappe, vous êtes presque assurés de retrouver vos données dans les tables MyISAM, avec la commande REPAIR TABLE. Si vos tables sont souvent corrompues, vous devrie toutefois rechercher la cause de ce problème! See Section A.4.2, « Que faire si MySQL plante constamment ? ». See Section 14.1.4, « Problèmes avec les tables MyISAM ».

REPAIR TABLE répare autant que possible les tables corrompues. La commande retourne la table suivante :

La commande REPAIR TABLE pourrait afficher plusieurs messages pour chaque table. La dernière ligne doit être du format Msg_type status et doit être normalement OK. Si vous n'obtenez pas OK, vous devez essayer de réparer votre table avec la commande myisamchk -o, car REPAIR TABLE de supporte pas encore toutes les options de myisamchk. Dans un futur proche, nous allons rendre cette commande encore plus souple.

Si l'option QUICK est fournie, alors MySQL va essayer de ne réparer que le fichier d'index. Ce type de réparation est le même que myisamchk --recover --quick.

Si vous utilisez l'option EXTENDED, alors MySQL va essayer de créer l'index ligne par ligne, au lieu de créer un index à la fois, par tri. C'est une méthode qui peut s'avérer plus efficace que de trier sur des clés de taille fixe, si vous avez des clés CHAR longues qui se compressent bien. Ce type de réparation est l'équivalent de myisamchk --safe-recover.

Depuis MySQL 4.0.2, il existe le mode USE_FRM pour REPAIR. Utilisez-le si le fichier .MYI manque, ou si son entête est corrompu. Avec ce mode, MySQL va recréer le fichier .MYI, en utilisant les informations du fichier .frm. Ce type de réparation ne peut pas être fait avec myisamchk.

Attention : si le serveur s'arrête durant l'opération REPAIR TABLE, il est important d'exécuter à nouveau la commande REPAIR TABLE après le redémarrage (il est bon de faire une sauvegarde de toutes manières). Dans le pire scénario, vous pourriez vous retrouver avec un nouvel index sans relation avec les données, et la prochaine opération risque d'écraser le fichier de données. C'est peu probable, mais possible.

Avant MySQL 4.1.1, les commandes REPAIR TABLE n'étaient pas écrites dans le log binaire. Depuis MySQL 4.1.1, elles sont écrites dans le log binaire à moins que la clause NO_WRITE_TO_BINLOG ne soit utilisée (aussi connue sous le nom de LOCAL).

RESTORE TABLE nom_de_table[,nom_de_table...] FROM '/chemin/vers/le/dossier/de/sauvegardes'

Restaure la ou les tables à partir d'une sauvegarde effectuée avec BACKUP TABLE. Les tables existantes ne seront pas écrasées et dans ce cas là, vous obtiendrez une erreur. La restauration prendra plus de temps que la sauvegarde à cause de la reconstruction du fichier d'index. Plus vous avez de clefs, plus la restauration sera longue. Tout comme BACKUP TABLE, RESTORE TABLE fonctionne seulement avec les tables MyISAM.

La sauvegarde de chaque table est constituée du fichier de format .frm et du fichier de données .MYD. L'opération de restauration restaure ces fichiers, puis les utilise pour reconstruire le fichier d'index .MYI. La restauration prend plus de temps que la sauvegarde, car il faut reconstituer l'index. Plus la table a d'index, plus cela prendra de temps.

Cette commande retourne un tableau avec les colonnes suivantes :

SET variable_assignment [, variable_assignment] ...

variable_assignment:
      user_var_name = expr
    | [GLOBAL | SESSION] system_var_name = expr
    | @@[global. | session.]system_var_name = expr

SET permet de configurer plusieurs options qui affectent le comportement de votre serveur ou de votre client.

En MySQL 4.0.3, nous avons ajouté les options GLOBAL et SESSION et permis la modification des variables systèmes les plus importantes dynamiquement, durant l'exécution du serveur. Le système de variables que vous pouvez utiliser est décrit dans Section 5.2.3.1, « Variables système dynamiques ».

Dans les anciennes versions de MySQL, nous avions autorisé l'utilisation de la syntaxe SET OPTION, mais elle est maintenant abandonnée. Omettez simplement le mot OPTION.

Les exemples suivants montrent les différentes syntaxes qu'on peut utiliser pour configurer des variables.

Une variable utilisateur s'écrit sous la forme @var_name et peut être configurée comme ceci :

SET @var_name = expr;

Plus d'informations sur les variables utilisateurs sont données dans Section 9.3, « Variables utilisateur ».

Les variables système peuvent être identifiées dans une commande SET sous la forme var_name. Le nom peut être optionnellement précédé par GLOBAL ou @@global. pour indiquer que cette variable est globale, ou par SESSION, @@session., ou @@ pour indiquer que cette variable est une variable de session. LOCAL et @@local. son synonymes de SESSION et @@session.. Si aucune option n'est présente, SET spécifie une variable de session.

La syntaxe @@var_name pour les variables système est supportée pour rendre la syntaxe MySQL compatible avec les autres bases.

Si vous configurez plusieurs variables sur une seule ligne de commande, le dernier mode GLOBAL | SESSION utilisé est pris en compte.

SET sort_buffer_size=10000;
SET @@local.sort_buffer_size=10000;
SET GLOBAL sort_buffer_size=1000000, SESSION sort_buffer_size=1000000;
SET @@sort_buffer_size=1000000;
SET @@global.sort_buffer_size=1000000, @@local.sort_buffer_size=1000000;

Si vous utilisez SESSION (par défaut) l'option que vous configurez garde son effet jusqu'à ce que la session courante se termine, ou que vous modifiez à nouveau cette option. Si vous utilisez GLOBAL, qui requière le privilège SUPER, l'option est gardée en mémoire et utilisée pour les nouvelles connexion jusqu'au redémarrage du serveur. Si vous voulez qu'un changement reste permanent, vous devez l'effectuer dans l'un des fichiers d'options de MySQL. See Section 4.3.2, « Fichier d'options my.cnf ».

Pour éviter un mauvais usage, MySQL donnera une erreur si vous utilisez SET GLOBAL avec une variable qui ne peut être inutilisée que par SET SESSION ou si vous n'utilisez pas SET GLOBAL avec une variable globale.

Si vous voulez configurer une variable SESSION à une valeur GLOBAL ou une valeur GLOBAL à la valeur par défaut de MySQL, vous pouvez la configurer à DEFAULT.

SET max_join_size=DEFAULT;
SET @@session.max_join_size=@@global.max_join_size;

Vous pouvez obtenir une liste de la plupart des variables avec SHOW VARIABLES. See Section 13.5.3.18, « Syntaxe de SHOW VARIABLES ». Vous pouvez obtenir la valeur d'une variable spécifique avec la syntaxe @@[global.|local.]nom_variable :

SHOW VARIABLES LIKE 'max_join_size';
SHOW GLOBAL VARIABLES LIKE 'max_join_size';

Vous pouvez aussi obtenir une valeur spécifique d'une variable en utilisant la syntaxe @@[global.|local.]var_name avec SELECT :

SELECT @@max_join_size, @@global.max_join_size;

Lorsque vous lisez la valeur d'une variable avec la syntaxe SELECT @@var_name (c'est à dire, sans spécifier global., session. ou local.), MySQL retourne la valeur de SESSION si elle existe, et la valeur GLOBAL sinon.

Vous trouverez ici une description des variables qui utilisent une syntaxe non-standard de SET. Les définitions des autres variables peuvent être trouvées dans la section des Section 5.2.3, « Variables serveur système », avec les options de démarrage ou dans la description de SHOW VARIABLES.

Même si ces variables ne sont pas affichées par SHOW VARIABLES, vous pouvez obtenir leur valeur avec la commande SELECT (à l'exception de CHARACTER SET). Par exemple :

mysql> SELECT @@AUTOCOMMIT;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+

La commande SHOW CHARACTER SET montre tous les jeux de caractères disponibles. Il faut une clause facultative LIKE pour limiter les jeux de caractères à afficher.

Par exemple :

mysql> SHOW CHARACTER SET LIKE 'latin%';
+---------+-----------------------------+-------------------+--------+
| Charset | Description                 | Default collation | Maxlen |
+---------+-----------------------------+-------------------+--------+
| latin1  | ISO 8859-1 West European    | latin1_swedish_ci |      1 |
| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |
| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |
| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |
+---------+-----------------------------+-------------------+--------+
4 rows in set (0.00 sec)

Remarques sur la liste précédente :

SHOW COLLATION [LIKE 'pattern']

Le résultat de SHOW COLLATION inclut tous les jeux de caractères disponibles. Vous pouvez utiliser optionnellement la clause LIKE pour limiter le nombre de réponses.

mysql> SHOW COLLATION LIKE 'latin1%';
+-------------------+---------+----+---------+----------+---------+
| Collation         | Charset | Id | Default | Compiled | Sortlen |
+-------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1  |  5 |         |          |       0 |
| latin1_swedish_ci | latin1  |  8 | Yes     | Yes      |       0 |
| latin1_danish_ci  | latin1  | 15 |         |          |       0 |
| latin1_german2_ci | latin1  | 31 |         | Yes      |       2 |
| latin1_bin        | latin1  | 47 |         | Yes      |       0 |
| latin1_general_ci | latin1  | 48 |         |          |       0 |
| latin1_general_cs | latin1  | 49 |         |          |       0 |
| latin1_spanish_ci | latin1  | 94 |         |          |       0 |
+-------------------+---------+----+---------+----------+---------+
7 rows in set (0.00 sec)

La colonne Default indique si une collation est la collation par défaut pour son jeu de caractères. Compiled indique si le jeu de caractères est compilé dans le serveur ou non. Sortlen est en relation avec la quantité de mémoire nécessaire pour trier des chaînes exprimées dans le jeu de caractéres.

SHOW [FULL] COLUMNS FROM tbl_name [FROM db_name] [LIKE 'pattern']

SHOW COLUMNS liste les colonnes de la table. Si les types de colonnes sont différents de ceux que vous avez utilisé avec la commande CREATE TABLE, c'est que MySQL a modifié silencieusement le type lors de la création. Les conditions de cette modification sont décrites dans Section 13.2.5.1, « Modification automatique du type de colonnes ».

Le mot clé FULL peut être utilisé depuis MySQL 3.23.32. Il fait afficher les droits dont vous disposez pour chaque colonne. Depuis MySQL 4.1, FULL affiche aussi les commentaires par colonne.

Vous pouvez utiliser db_name.tbl_name comme syntaxe alternative à tbl_name FROM db_name. Ces deux commandes sont équivalentes :

mysql> SHOW COLUMNS FROM mytable FROM mydb;
mysql> SHOW COLUMNS FROM mydb.mytable;

SHOW FIELDS est un synonyme de SHOW COLUMNS. Vous pouvez aussi lister les colonnes d'une table avec la commande mysqlshow db_name tbl_name.

La commande DESCRIBE fournit une information similaire à SHOW COLUMNS. See Section 13.3.1, « Syntaxe de DESCRIBE (obtenir des informations sur les colonnes) ».

SHOW CREATE DATABASE db_name

La requête suivante montre une commande CREATE DATABASE qui va créer une base de donnée. Commande ajoutée en MySQL 4.1.

mysql> SHOW CREATE DATABASE test\G
*************************** 1. row ***************************
       Database: test
Create Database: CREATE DATABASE `test`
                 /*!40100 DEFAULT CHARACTER SET latin1 */

SHOW CREATE TABLE tbl_name

Affiche la commande CREATE TABLE nécessaire pour créer une table donnée.

mysql> SHOW CREATE TABLE t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE t (
  id int(11) default NULL auto_increment,
  s char(60) default NULL,
  PRIMARY KEY (id)
) TYPE=MyISAM

SHOW CREATE TABLE va protéger le nom de la table et des colonnes selon l'option SQL_QUOTE_SHOW_CREATE. Section 13.5.2.8, « Syntaxe de SET ».

SHOW {DATABASES | SCHEMAS} [LIKE 'pattern']

SHOW DATABASES liste les bases de données disponible sur le serveur MySQL. Vous pouvez aussi obtenir cette liste avec l'utilitaire mysqlshow. Depuis MySQL 4.0.2, vous ne verrez que les bases pour lesquelles vous avez des droits, à moins que vous n'ayez le droit de SHOW DATABASES.

Si le serveur a été lancé avec l'option --skip-show-database, vous ne pouvez pas utiliser cette commande à moins que vous n'ayez le droit de SHOW DATABASES.

SHOW SCHEMAS est disponible depuis MySQL 5.0.2

SHOW [STORAGE] ENGINES

SHOW ENGINES affiche les informations sur les moteurs de stockage du serveur. C'est particulièrement utile pour connaître les moteurs supportés par votre serveur, ou le moteur par défaut. Cette commande a été ajoutée en MySQL 4.1.2. SHOW TABLE TYPES est un synonyme, mais est abandonnée.

mysql> SHOW ENGINES\G
*************************** 1. row ***************************
   Type: MyISAM
Support: DEFAULT
Comment: Default type from 3.23 with great performance
*************************** 2. row ***************************
   Type: HEAP
Support: YES
Comment: Hash based, stored in memory, useful for temporary tables
*************************** 3. row ***************************
   Type: MEMORY
Support: YES
Comment: Alias for HEAP
*************************** 4. row ***************************
   Type: MERGE
Support: YES
Comment: Collection of identical MyISAM tables
*************************** 5. row ***************************
   Type: MRG_MYISAM
Support: YES
Comment: Alias for MERGE
*************************** 6. row ***************************
   Type: ISAM
Support: NO
Comment: Obsolete table type; Is replaced by MyISAM
*************************** 7. row ***************************
   Type: MRG_ISAM
Support: NO
Comment: Obsolete table type; Is replaced by MRG_MYISAM
*************************** 8. row ***************************
   Type: InnoDB
Support: YES
Comment: Supports transactions, row-level locking and foreign keys
*************************** 9. row ***************************
   Type: INNOBASE
Support: YES
Comment: Alias for INNODB
*************************** 10. row ***************************
   Type: BDB
Support: YES
Comment: Supports transactions and page-level locking
*************************** 11. row ***************************
   Type: BERKELEYDB
Support: YES
Comment: Alias for BDB

La valeur Support indique que le moteur est supporté, et si le moteur est le moteur par défaut. Par exemple, si le serveur est lancé avec l'option --default-table-type=InnoDB alors la valeur de la colonne Support de la ligne InnoDB contiendra DEFAULT.

SHOW ERRORS [LIMIT [offset,] row_count]
SHOW COUNT(*) ERRORS

Cette commande est similaire à SHOW WARNINGS, hormis le fait qu'au lieu d'afficher les erreurs, alertes et notes, elle n'affiche que les erreurs. SHOW ERRORS est disponible depuis MySQL 4.1.0.

La clause LIMIT a la même syntaxe que celle de la commande SELECT. See Section 13.1.7, « Syntaxe de SELECT ».

La commande SHOW COUNT(*) ERRORS affiche le nombre d'erreurs. Vous pouvez aussi connaître ce nombre en lisant la variable error_count :

SHOW COUNT(*) ERRORS;
SELECT @@error_count;

Pour plus d'informations, voyez Section 13.5.3.19, « SHOW WARNINGS | ERRORS ».

SHOW GRANTS FOR user

SHOW GRANTS FOR user affiche la commande nécessaire pour donner les même droits qu'un utilisateur existant.

mysql> SHOW GRANTS FOR 'root'@'localhost';
+---------------------------------------------------------------------+
| Grants for root@localhost                                           |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+

Depuis MySQL 4.1.2, pour lister les droits de la session courante, vous pouvez connaître le nom d'utilisateur de la session avec ces commandes :

SHOW GRANTS;
SHOW GRANTS FOR CURRENT_USER;
SHOW GRANTS FOR CURRENT_USER();

Avant MySQL 4.1.2, vous pouviez connaître le nom d'identification de l'utilisation avec la fonction CURRENT_USER() (nouveau en MySQL 4.0.6). Puis, utilisez cette valeur avec la commande SHOW GRANTS. See Section 12.8.3, « Fonctions d'informations ».

SHOW GRANTS est disponible depuis MySQL 3.23.4.

SHOW INDEX FROM tbl_name [FROM db_name]

SHOW INDEX retourne les informations sur les index de la table, dans un format proche de celui de SQLStatistics en ODBC.

SHOW INDEX retourne les champs suivants :

Les colonnes Packed et Comment ont été ajoutée en MySQL 3.23.0. Les colonnes Null et Index_type ont été ajoutées en MySQL 4.0.2.

Vous pouvez utiliser la syntaxe db_name.tbl_name comme alternative à tbl_name FROM db_name. Ces deux commandes sont équivalentes :

mysql> SHOW INDEX FROM mytable FROM mydb;
mysql> SHOW INDEX FROM mydb.mytable;

SHOW KEYS est un synonyme SHOW INDEX. Vous pouvez aussi lister les index d'une table avec la commande en ligne mysqlshow -k db_name tbl_name.

SHOW INNODB STATUS

Cette commente donne des informations exhaustives sur le moteur de stockage InnoDB.

SHOW [BDB] LOGS

La commande SHOW LOGS affiche les informations d'état de vos fichiers de logs. Actuellement, elle n'affiche que les informations pour les fichiers de log des tables Berkeley DB.

SHOW PRIVILEGES

Cette commande est implémentée en MySQL 4.1.0.

SHOW PRIVILEGES affiche la liste des droits que le serveur MySQL supporte.

mysql> show privileges;
+------------+--------------------------+-------------------------------------------------------+
| Privilege  | Context                  | Comment                                               |
+------------+--------------------------+-------------------------------------------------------+
| Select     | Tables                   | Lire des lignes d'une table                           |
| Insert     | Tables                   | Insérer des lignes dans une table                     |
| Update     | Tables                   | Modifier les lignes existantes                        |
| Delete     | Tables                   | Effacer des lignes existantes                         |
| Index      | Tables                   | Créer ou effacer des indexs                           |
| Alter      | Tables                   | Modifier la structure d'une table                     |
| Create     | Databases,Tables,Indexes | Créer une nouvelle base ou table                      |
| Drop       | Databases,Tables         | Effacer une base ou table                             |
| Grant      | Databases,Tables         | Donner à d'autres les droits courants                 |
| References | Databases,Tables         | Avoir des références sur les tables                   |
| Reload     | Server Admin             | Rafraîchir les droits, tables et logs                 |
| Shutdown   | Server Admin             | Eteindre le serveurver                                |
| Process    | Server Admin             | Voir la version texte des requêtes en cours           |
| File       | File access on server    | Lire et écrire des fichiers sur le serveur            |
+------------+--------------------------+-------------------------------------------------------+
14 rows in set (0.00 sec)

SHOW [FULL] PROCESSLIST

SHOW [FULL] PROCESSLIST affiche la liste de processus qui sont en cours d'exécution. Vous pouvez aussi obtenir ces informations avec la commande en ligne mysqladmin processlist. Si vous avez les droits de SUPER, vous pourrez aussi voir les autres threads. Sinon, vous ne pourrez voir que les votre. See Section 13.5.4.3, « Syntaxe de KILL ». Si vous n'utilisez pas l'option FULL, seuls les 100 premiers caractères de chaque requête seront affichés.

Cette commande est très pratique si vous obtenez trop d'erreurs ‘too many connections’ et que vous voulez savoir ce qui se passe. MySQL réserve une connexion supplémentaire pour un client ayant les droits de SUPER, de fa¸on à ce qu'il y ait toujours la possibilité de se connecter et de vérifier le système (en supposant que vous ne donnez pas ce droit à tous vos utilisateurs).

Certains états sont souvent disponible dans le résultat de mysqladmin processlist

La plupart des états sont des opérations très rapides. Si le thread s'attarde dans un de ces états pour plusieurs secondes, il doit y avoir un problème qui mérite d'être étudié.

Il existe encore d'autres états qui ne sont pas mentionné ci-dessus, mais la majorité sont utilisés pour trouver des bogues dans mysqld.

SHOW STATUS [LIKE 'pattern']

SHOW STATUS affiche des informations sur le statut du serveur. Cette information est aussi accessible avec la commande la commande mysqladmin extended-status.

Un résultat partiel est présenté ci-dessous. La liste complète des variables dépend de votre serveur. Leur signification individuelle est présentée dans la section See Section 5.2.4, « Variables de statut du serveur  ».

mysql> SHOW STATUS;
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| Aborted_clients          | 0          |
| Aborted_connects         | 0          |
| Bytes_received           | 155372598  |
| Bytes_sent               | 1176560426 |
| Connections              | 30023      |
| Created_tmp_disk_tables  | 0          |
| Created_tmp_tables       | 8340       |
| Created_tmp_files        | 60         |
...
| Open_tables              | 1          |
| Open_files               | 2          |
| Open_streams             | 0          |
| Opened_tables            | 44600      |
| Questions                | 2026873    |
...
| Table_locks_immediate    | 1920382    |
| Table_locks_waited       | 0          |
| Threads_cached           | 0          |
| Threads_created          | 30022      |
| Threads_connected        | 1          |
| Threads_running          | 1          |
| Uptime                   | 80380      |
+--------------------------+------------+

Avec la clause LIKE, la commande peut limiter l'affichage des variables à celles qui vérifient un masque :

mysql> SHOW STATUS LIKE 'Key%';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| Key_blocks_used    | 14955    |
| Key_read_requests  | 96854827 |
| Key_reads          | 162040   |
| Key_write_requests | 7589728  |
| Key_writes         | 3813196  |
+--------------------+----------+

SHOW TABLE STATUS [FROM db_name] [LIKE wild]

SHOW TABLE STATUS (nouveau en version 3.23) fonctionne comme SHOW STATUS, mais fournit des informations sur les tables. Vous pouvez aussi obtenir ces informations en utilisant la commande en ligne mysqlshow --status db_name. Les données suivantes sont retournées :

Les tables InnoDB indiqueront l'espace disque libre dans le commentaire de table.

SHOW [OPEN] TABLES [FROM db_name] [LIKE 'pattern']

SHOW TABLES liste les tables permanentes (non TEMPORARY) dans une base de données. Vous pouvez obtenir cette liste avec la commande en ligne mysqlshow db_name.

Note : Si vous n'avez pas les droits sur une table, la table n'apparaîtra pas dans le résultat de SHOW TABLES et mysqlshow db_name.

SHOW OPEN TABLES liste les tables qui sont actuellement ouvertes dans le cache de table. See Section 7.4.8, « Quand MySQL ouvre et ferme les tables ». Le champ Comment du résultat indique le nombre d'ouverture de la table en cache (cached) et le nombre d'utilisation (in_use). OPEN est disponible depuis MySQL 3.23.33.

SHOW [GLOBAL | SESSION] VARIABLES [LIKE 'pattern']

SHOW VARIABLES affiche les valeurs des variables systèmes de MySQL. Vous pouvez aussi obtenir ces informations avec la commande mysqladmin variables.

Les options GLOBAL et SESSION ont été ajoutées en MySQL 4.0.3. Avec GLOBAL, vous obtiendrez les valeurs qui seront utilisées pour les nouvelles connexions au serveur MySQL. Avec SESSION, vous recevez les valeurs effectives pour la connexion en cours. Si vous ne précisez ni l'une ni l'autre, la valeur par défaut est SESSION. LOCAL est un synonyme de SESSION.

Si les valeurs par défaut ne vous conviennent pas, vous pouvez modifier la plupart de ces variables, en ligne de commande, lorsque mysqld est lancé. Voir Section 5.2.1, « Options de ligne de commande de mysqld » et Section 13.5.2.8, « Syntaxe de SET ».

Voici un extrait du résultat de la commande. La liste complète des variables et de leur valeur peut être différente pour votre serveur. La signification de chaque variable est présentée dans See Section 5.2.3, « Variables serveur système ». Des informations sur comment optimiser ces valeurs sont disponibles dans la section Section 7.5.2, « Réglage des paramètres du serveur ».

mysql> SHOW VARIABLES;
+---------------------------------+------------------------------+
| Variable_name                   | Value                        |
+---------------------------------+------------------------------|
| back_log                        | 50                           |
| basedir                         | /usr/local/mysql             |
| bdb_cache_size                  | 8388572                      |
| bdb_log_buffer_size             | 32768                        |
| bdb_home                        | /usr/local/mysql             |
...
| max_connections                 | 100                          |
| max_connect_errors              | 10                           |
| max_delayed_threads             | 20                           |
| max_error_count                 | 64                           |
| max_heap_table_size             | 16777216                     |
| max_join_size                   | 4294967295                   |
| max_relay_log_size              | 0                            |
| max_sort_length                 | 1024                         |
...
| timezone                        | EEST                         |
| tmp_table_size                  | 33554432                     |
| tmpdir                          | /tmp/:/mnt/hd2/tmp/          |
| version                         | 4.0.4-beta                   |
| wait_timeout                    | 28800                        |
+---------------------------------+------------------------------+

Avec la clause LIKE, la commande n'affichera que les variables qui vérifie le masque fourni :

mysql> SHOW VARIABLES LIKE 'have%';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| have_bdb           | YES      |
| have_innodb        | YES      |
| have_isam          | YES      |
| have_raid          | NO       |
| have_symlink       | DISABLED |
| have_openssl       | YES      |
| have_query_cache   | YES      |
+--------------------+----------+

SHOW WARNINGS [LIMIT [offset,] row_count]
SHOW COUNT(*) WARNINGS

Cette commande affiche les erreurs, alertes et notes qui ont été générées par la dernière commande. Les erreurs et alertes sont remises à zéro pour chaque nouvelle commande qui utilisent une table. Cette commande a été implémentée depuis MySQL 4.1.0. Une commande connexe, SHOW ERRORS, affiche uniquement les erreurs. See Section 13.5.3.8, « Syntaxe de SHOW ERRORS ».

La liste de messages est remise à zéro au début de chaque commande qui utilise la table.

La commande SHOW COUNT(*) WARNINGS affiche le nombre total d'erreurs, d'alertes et de notes. Vous pouvez aussi lire ce nombre avec la variable warning_count :

SHOW COUNT(*) WARNINGS;
SELECT @@warning_count;

La valeur de warning_count peut être plus grande que le nombre de messages affichés par SHOW WARNINGS si la variable système max_error_count est configurée assez bas pour que tous les messages ne soient pas stockés. Un exemple plus loin dans cette section montre ce qui arrive.

La clause LIMIT a la même syntaxe que la commande SELECT. See Section 13.1.7, « Syntaxe de SELECT ».

Le serveur MySQL retourne le nombre total d'alertes et d'erreurs que vous avez obtenu lors de la dernière commande. Ils sont disponibles avec la fonction mysql_warning_count(). See Section 24.2.3.61, « mysql_warning_count() ».

Jusqu'à max_error_count messages peuvent être stockés (variable globale et spécifique aux threads).

Vous pouvez lire le nombre d'erreurs dans @error_count et le nombre d'alertes dans @warning_count.

SHOW WARNINGS affiche aussi toutes les erreurs, alertes et notes de la dernière commande, alors que SHOW ERRORS ne montre que les erreurs.

mysql> DROP TABLE IF EXISTS no_such_table;
mysql> SHOW WARNINGS;

+-------+------+-------------------------------+
| Level | Code | Message                       |
+-------+------+-------------------------------+
| Note  | 1051 | Unknown table 'no_such_table' |
+-------+------+-------------------------------+

Notez que depuis MySQL 4.1.0, nous avons ajouté un nouveau système d'alertes, et peu de commandes MySQL génère des alertes. 4.1.1 supporte toutes sortes d'alertes pour LOAD DATA INFILE et les commandes DML telles que INSERT, UPDATE et ALTER.

Par exemple, voici une situation simple qui produit des alertes de conversions pour une commande d'insertion :

mysql> create table t1(a tinyint NOT NULL, b char(4));
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t1 values(10,'mysql'),(NULL,'test'),(300,'open source');
Query OK, 3 rows affected, 4 warnings (0.15 sec)
Records: 3  Duplicates: 0  Warnings: 4

mysql> show warnings;
+---------+------+---------------------------------------------------------------+
| Level   | Code | Message                                                       |
+---------+------+---------------------------------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1                        |
| Warning | 1261 | Data truncated, NULL supplied to NOT NULL column 'a' at row 2 |
| Warning | 1262 | Data truncated, out of range for column 'a' at row 3          |
| Warning | 1263 | Data truncated for column 'b' at row 3                        |
+---------+------+---------------------------------------------------------------+
4 rows in set (0.00 sec)

Le nombre maximal d'alertes peut être spécifié en utilisant la variable de serveur 'max_error_count', SET max_error_count=[count]; Par défaut, c'est 64. Pour désactiver les alertes, donnez simplement la valeur de 0 à la variable. Si max_error_count vaut 0, alors le nombre d'alertes représente toujours le nombre d'alertes qui ont eu lieu, mais aucun message d'erreur n'est accessible.

Par exemple, observez la commande ALTER suivante, pour l'exemple ci-dessus, qui retourne uniquement une alerte, même si le nombre total d'alertes est de 3 lorsque 'max_error_count'=1.

mysql> show variables like 'max_error_count';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_error_count | 64    |
+-----------------+-------+
1 row in set (0.00 sec)

mysql> set max_error_count=1;
Query OK, 0 rows affected (0.00 sec)

mysql> alter table t1 modify b char;
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 3

mysql> show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)

mysql>

CACHE INDEX
  table_index_list [, table_index_list] ...
  IN key_cache_name

table_index_list:
  tbl_name [[INDEX] (index_name[, index_name] ...)]

La commande CACHE INDEX assigne un index de table à un cache de clé spécifique. Cette commande est uniquement disponible pour les tables MyISAM.

La commande suivante assigne les index des tables t1, t2 et t3 au cache de clé appelé hot_cache :

mysql> CACHE INDEX t1, t2, t3 IN hot_cache;
+---------+--------------------+----------+----------+
| Table   | Op                 | Msg_type | Msg_text |
+---------+--------------------+----------+----------+
| test.t1 | assign_to_keycache | status   | OK       |
| test.t2 | assign_to_keycache | status   | OK       |
| test.t3 | assign_to_keycache | status   | OK       |
+---------+--------------------+----------+----------+

La syntaxe de CACHE INDEX vous permet de spécifier des index particuliers à un cache. Cependant, l'implémentation courante assigne tous les index de la table au cache, et il n'y a donc pas d'intérêt à spécifier autre chose que le nom de la table.

Le cache de clé utilisé dans une commande CACHE INDEX peut être créé en lui donnant une taille avec une commande de configuration, ou la configuration du serveur. Par exemple :

mysql> SET GLOBAL keycache1.key_buffer_size=128*1024;

Les paramètres du cache de clé sont accessibles depuis une variable système structurée. See Section 9.4.1, « Variables système structurées ».

Un cache de clé doit exister avant que vous ne l'utilisiez :

mysql> CACHE INDEX t1 in non_existent_cache;
ERROR 1283 (HY000): Unknown key cache 'non_existent_cache'

Par défaut, les index de table sont assignée au cache de clé par défaut, créé au moment du démarrage du serveur. Lorsqu'un cache de clé est détruit, tous les index qui lui étaient assigné sont transmis au cache par défaut.

Les assignations d'index affectent le serveur globalement : si un client assigne un index à un cache donné, ce cache sera utilisé pour tous les requêtes, quelque soit le client qui émet la requête.

CACHE INDEX a été ajouté en MySQL 4.1.1.

FLUSH flush_option [,flush_option] ...

Vous devez utiliser la commande FLUSH si vous voulez effacer certains caches internes de MySQL. Pour exécuter FLUSH, vous devez avoir le droit RELOAD.

flush_option peut être l'une des suivantes :

Vous pouvez aussi accéder à toutes les commandes décrites plus haut en les donnant en arguments à mysqladmin (exemple : flush-hosts, flush-logs, reload, ou encore flush-tables).

Reportez-vous aussi à la commande RESET avec la réplication. See Section 13.5.4.5, « Syntaxe de la commande RESET ».

KILL [CONNECTION | QUERY] thread_id

Chaque connexion à mysqld utilise un thread unique. Vous pouvez voir les threads en cours d'exécution en utilisant la commande SHOW PROCESSLIST et en terminer un avec la commande KILL thread_id.

Depuis MySQL 5.0.0, KILL autorise les options CONNECTION et QUERY :

Si vous avez le droit PROCESS, vous pouvez voir tous les threads. Si vous avez le droit SUPER, vous pouvez terminer tout les threads. Sinon, vous ne pouvez terminer que vos propres threads.

Vous pouvez aussi utiliser les commandes mysqladmin processlist et mysqladmin kill pour examiner et terminer les threads.

Note : vous ne pouvez actuellement pas utiliser KILL avec la bibliothèque du serveur embarqué, car celui-ci utilise les threads de l'application hôte, il ne crée pas ses propres threads.

Quand vous exécutez un KILL, un thread spécifique est crée pour ce thread.

Dans la plupart des cas, la terminaison du thread pourra prendre un certain temps vu que le thread de terminaison est invoqué à intervalles spécifiques.

LOAD INDEX INTO CACHE
  table_index_list [, table_index_list] ...

table_index_list:
  tbl_name
    [[INDEX] (index_name[, index_name] ...)]
    [IGNORE LEAVES]

La commande LOAD INDEX INTO CACHE précharge un index dans un cache de clé, qui est explicitement nommé dans dans la commande CACHE INDEX, ou dans le cache par défaut. LOAD INDEX INTO CACHE ne sert que pour les tables MyISAM.

L'option IGNORE LEAVES fait que les blocs terminaux de l'index ne sont pas lus.

La commande suivante précharge les noeuds des tables t1 et t2 :

mysql> LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;
+---------+--------------+----------+----------+
| Table   | Op           | Msg_type | Msg_text |
+---------+--------------+----------+----------+
| test.t1 | preload_keys | status   | OK       |
| test.t2 | preload_keys | status   | OK       |
+---------+--------------+----------+----------+

Cette commande charge tous les index de t1. Elle ne charge que les index non-terminaux de t2.

La syntaxe de LOAD INDEX INTO CACHE vous permet de spécifier seulement des index particuliers à charger dans la table. Cependant, l'implémentation courante charge tous les index : il n' y a pas de raison pour utiliser autre chose que le nom de la table.

LOAD INDEX INTO CACHE a été ajouté en MySQL 4.1.1.

RESET reset_option [, reset_option] ...

La commande RESET sert à remettre à zéro des données. C'est aussi une version plus puissante de la commande FLUSH. See Section 13.5.4.2, « Syntaxe de FLUSH ».

Pour exécuter la commande RESET, vous devez avoir les droits RELOAD.

PURGE {MASTER | BINARY} LOGS TO 'log_name'
PURGE {MASTER | BINARY} LOGS BEFORE 'date'

Efface tous les logs binaires listés dans l'index de logs, qui sont antérieurs à la date ou au log indiqué. Les logs sont aussi supprimés de cette liste : le log donné en paramètre devient alors le premier de la liste.

Exemple :

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';

La variante BEFORE est disponible en MySQL 4.1; son argument de date peut être au format 'YYYY-MM-DD hh:mm:ss'. MASTER et BINARY sont synonymes, mais BINARY ne peut être utilisé que depuis MySQL 4.1.1.

Si vous avez un esclave actif qui est actuellement en train de lire l'un des logs que vous voulez effacer, la commande ne fera rien, et échouera avec une erreur. Cependant, si l'esclave est inactif, et que vous effacez un des logs qu'il utilisait, l'esclave sera incapable de reprendre la réplication. Cette commande peut être utilisée sans problème durant la réplication : vous n'avez pas besoin d'arrêter les esclaves.

Pour purger les logs, suivez cette procédure :

RESET MASTER

Efface tous les fichiers de logs binaires dans le fichier d'index, et vide le fichier d'index des logs.

Cette commande s'appelait FLUSH MASTER avant MySQL 3.23.26.

SET SQL_LOG_BIN = {0|1}

Inactive ou active le log binaire de la connexion courante (SQL_LOG_BIN est une variable de session), si le client se connecte avec un compte qui a les droits de SUPER. La commande est ignorée si le client n'a pas de droits.

SHOW BINLOG EVENTS [ IN 'log_name' ] [ FROM pos ] [ LIMIT [offset,] row_count ]

Affiche les événements du log binaire. Si vous ne spécifiez pas 'log_name', le premier log binaire sera affiché.

La clause LIMIT a la même syntaxe que celle de la commande SELECT. See Section 13.1.7, « Syntaxe de SELECT ».

Cette commande est disponible en MySQL 4.0

SHOW MASTER LOGS

Liste les logs binaires disponibles sur le maître. Vous devriez utiliser cette commande avant PURGE MASTER LOGS pour savoir jusqu'où vous pouvez aller.

SHOW MASTER STATUS

Affiche les informations d'état du log binaire du maître.

SHOW SLAVE HOSTS

Affiche la liste des esclaves actuellement enregistrée sur le maître. Notez que les esclaves qui ne sont pas lancé avec l'option --report-host=nom_d_esclave ne seront pas visible dans cette liste.

CHANGE MASTER TO master_def [, master_def] ...

master_def =
      MASTER_HOST = 'host_name'
    | MASTER_USER = 'user_name'
    | MASTER_PASSWORD = 'password'
    | MASTER_PORT = port_num
    | MASTER_CONNECT_RETRY = count
    | MASTER_LOG_FILE = 'master_log_name'
    | MASTER_LOG_POS = master_log_pos
    | RELAY_LOG_FILE = 'relay_log_name'
    | RELAY_LOG_POS = relay_log_pos
    | MASTER_SSL = {0|1}
    | MASTER_SSL_CA = 'ca_file_name'
    | MASTER_SSL_CAPATH = 'ca_directory_name'
    | MASTER_SSL_CERT = 'cert_file_name'
    | MASTER_SSL_KEY = 'key_file_name'
    | MASTER_SSL_CIPHER = 'cipher_list'

Modifie les paramètres que l'esclave utilise pour se connecter et pour communiquer avec le serveur maître. Les valeurs possibles pour master_def sont présentées ci-dessus.

Les options de log de relais, RELAY_LOG_FILE et RELAY_LOG_POS, sont disponibles depuis MySQL 4.0.

Les options SSL, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY et MASTER_SSL_CIPHER, sont disponibles depuis MySQL 4.1.1. Vous pouvez changer ces options même sur les esclaves qui sont compilé sans le support SSL. Elles seront sauvées dans le fichier master.info mais ignorées jusqu'à ce que le support SSL soit activé.

Par exemple :

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master2.mycompany.com',
    ->     MASTER_USER='replication',
    ->     MASTER_PASSWORD='bigs3cret',
    ->     MASTER_PORT=3306,
    ->     MASTER_LOG_FILE='master2-bin.001',
    ->     MASTER_LOG_POS=4,
    ->     MASTER_CONNECT_RETRY=10;
mysql> CHANGE MASTER TO
    ->     RELAY_LOG_FILE='slave-relay-bin.006',
    ->     RELAY_LOG_POS=4025;

MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, et MASTER_SSL_CIPHER sont des informations qui permettent à l'esclave de se connecter au maître. Si vous omettez certains paramètres, les paramètres omis conserveront leur ancienne valeur. Par exemple, si le mot de passe sur le maître a changé, il suffit de faire :

mysql> STOP SLAVE; -- if replication was running
mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cret';
mysql> START SLAVE; -- if you want to restart replication

pour indiquer à l'esclave le nouveau mot de passe : il n'y a pas besoin de spécifier les informations qui n'ont pas changé, comme l'hôte, le port, l'utilisateur, etc...

MASTER_HOST, MASTER_PORT sont le nom d'hôte ou l'adresse IP du maître, et son port TCP. Notez que si MASTER_HOST est égal à localhost, alors, comme généralement avec MySQL, le port sera ignoré si les sockets Unix sont utilisables.

Si vous spécifiez MASTER_HOST ou MASTER_PORT, l'esclave supposera que le serveur maître est différent du précédent, même si vous spécifier les mêmes valeurs d'hôte et de port que précédemment. Dans ce cas, les anciennes valeurs et position de l'historique binaire ne sont plus valides. Ainsi, si vous ne spécifiez pas MASTER_LOG_FILE et MASTER_LOG_POS dans la commande, MASTER_LOG_FILE='' et MASTER_LOG_POS=4 sont ajoutés silencieusement.

MASTER_LOG_FILE et MASTER_LOG_POS sont les coordonnées auxquelles le thread d'I/O doit commencer à lire chez le maître, lorsque le thread redémarrera. Si vous spécifiez l'un d'entre eux, vous ne pourrez pas spécifier RELAY_LOG_FILE ou RELAY_LOG_POS. Si MASTER_LOG_FILE, ni MASTER_LOG_POS n'ont été spécifiés, alors les dernières coordonnées du thread esclave d'avant la commande CHANGE MASTER seront utilisées. Cela assure que la réplication ne connaît pas de discontinuité, même si le thread esclave était en retard sur le thread d'I/O, alors que vous ne voulez changer que le mot de passe. Ce comportement sécuritaire a été introduit à partir de MySQL versions 4.0.17 et 4.1.1. Avant ces versions, les coordonnées utilisées celles du thread d'I/O, avant que la commande CHANGE MASTER soit émise, ce qui conduisait à des pertes d'événements au niveau du maître, et donc, la corruption de la réplication.

CHANGE MASTER efface tous les logs de relais (et en démarre de nouveaux), à moins que vous ne spécifiez l'option RELAY_LOG_FILE ou RELAY_LOG_POS (dans ce cas, les logs de relais seront conservés; depuis MySQL 4.1.1 la variable globale RELAY_LOG_PURGE sera automatiquement mise à 0). CHANGE MASTER TO modifie master.info et relay-log.info.

CHANGE MASTER sert à configurer un esclave lorsque vous avez une sauvegarde du maître, son log et la position qui correspond à la sauvegarde du maître. Vous pouvez utiliser la commande CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master sur l'esclave après la restauration de la sauvegarde.

Le premier exemple ci-dessus (CHANGE MASTER TO MASTER_HOST='master2.mycompany.com' etc) modifie les coordonnées du maître et de son log binaire. Cela est utile lorsque vous voulez que l'esclave réplique le maître. Le second exemple, moins fréquent, sert lorsque l'esclave a des logs de relais que vous voulez utiliser à nouveau. Pour cela, le maître n'a pas besoin d'être rejoint : il suffit d'utiliser la commande CHANGE MASTER TO et de lancer le thread SQL START SLAVE SQL_THREAD. Vous pouvez même utiliser cela dans une configuration de réplication, sur un serveur indépendant, pour assurer la restauration après crash. Supposez que votre serveur soit planté, et que vous avez restauré la sauvegarde. Vous voulez que le serveur exécute à nouveau ses propres logs (non pas des logs de relais, mais ses logs binaires), qui sont par exemple, stockés sous le nom myhost-bin.*. Tout d'abord, faite une copie des fichiers de log dans un entrepôt, au cas où une erreur de manipulation surviendrait, et que le serveur vide ses logs. Si vous utilisez MySQL 4.1.1 ou plus récent, utilisez la commande suivante pour plus de sécurité : SET GLOBAL RELAY_LOG_PURGE=0.

Puis, lancez le serveur sans log-bin, et avec un nouvel identifiant (différent du précédent), avec l'option relay-log=myhost-bin (pour faire croire au serveur que ses propres logs sont des logs de relais), et skip-slave-start. Puis, envoyez cette commande :

mysql> CHANGE MASTER TO
    ->     RELAY_LOG_FILE='myhost-bin.153',
    ->     RELAY_LOG_POS=410,
    ->     MASTER_HOST='some_dummy_string';
mysql> START SLAVE SQL_THREAD;

Le serveur va alors lire et exécuter ses propres logs, et rattraper les données jusqu'au crash.

Une fois la restauration finie, faites STOP SLAVE, éteignez le serveur, supprimez master.info et relay-log.info, puis relancez le serveur avec ses options originales.

Pour le moment, spécifier MASTER_HOST (même avec une valeur insignifiante) est obligatoire pour que le serveur pense qu'il est un esclave. Donner au serveur un nouvel identifiant, différent du précédent, est aussi obligatoire, car sinon, le serveur va voir des événements avec son identifiant, et il va conclure que c'est une réplication circulaire, et il va les ignorer. Dans le futur, nous envisageons de nous débarasser de ces petites contraintes.

LOAD DATA FROM MASTER

Fait une sauvegarde du maître et la copie vers l'esclave. Met à jour les valeurs de MASTER_LOG_FILE et MASTER_LOG_POS pour que la réplication reprennent à la bonne position. Respecte les interdictions de réplications de tables et de bases spécifiées par les options replicate-*.

L'utilisation de cette commande est sujette aux conditions suivantes :

Dans le futur, il est prévu de faire que cette commande fonctionne avec les tables InnoDB, et qu'elle se passe du verrou global en utilisant des fonctionnalités de sauvegarde à chaud non-bloquantes.

Si vous chargez de très grosses tables, pensez à augmenter les valeurs des options net_read_timeout et net_write_timeout sur vos maître et esclave. See Section 5.2.3, « Variables serveur système ».

Notez que LOAD DATA FROM MASTER ne copie pas les tables de droits de la base mysql. C'est fait pour simplifier l'utilisation de droits et utilisateurs différents sur le maître et les esclaves.

Cette commande requiert les droits de RELOAD et SUPER sur le maître, et le droit de SELECT sur toutes les tables du maître qui seront lues. Toutes les tables du maître sur lesquelles l'utilisateur n'a pas de droits de SELECT seront ignorées par LOAD DATA FROM MASTER; ceci est dû au fait que le maître va masquer ces tables à l'utilisateur : LOAD DATA FROM MASTER utilise SHOW DATABASES pour connaître les tables à charger, mais SHOW DATABASES ne retourne que les bases pour lesquelles l'utilisateur a des droits. Voyez Section 13.5.3.6, « Syntaxe de SHOW DATABASES ». Sur l'esclave, l'utilisateur qui envoie la commande LOAD DATA FROM MASTER doit avoir les droits de création et d'effacement des tables et bases impliquées.

LOAD TABLE tbl_name FROM MASTER

Télécharge une copie d'une table depuis le maître vers l'esclave. Cette commande est implémentée pour déboguer la commande LOAD DATA FROM MASTER. Elle requiert un compte pour se connecter au maître, avec les droits de RELOAD et SUPER, ainsi que les droits de SELECT sur la table a charger. Coté esclave, l'utilisateur qui émet la commande doit avoir les droits de LOAD TABLE FROM MASTER pour créer et effacer les tables. Lisez les informations sur les problèmes réseau dans LOAD DATA FROM MASTER; elles s'appliquent aussi ici. Notez aussi que les limitations de LOAD DATA FROM MASTER s'appliquent aussi (par exemple, LOAD TABLE FROM MASTER ne fonctionne que sur les tables de type MyISAM).

SELECT MASTER_POS_WAIT('master_log_file', master_log_pos)

C'est une fonction et non pas une commande. Elle sert à s'assurer que l'esclave a atteint (lu et exécuté) les événements du log binaire du maître jusqu'à une certaine position. Voyez la section See Section 12.8.4, « Fonctions diverses » pour une description complète.

RESET SLAVE

Force l'esclave a oublier toute les positions de réplications dans les logs du maître. Cette commande permet de faire un démarrage propre : elle efface les fichiers master.info et relay-log.info, et les logs de relais, puis créer un nouveau log de relais.

Note : tous les logs de relais sont effacés, même si il n'ont pas été totalement exécutés par le thread SQL. (C'est un état qui est probable si l'esclave de réplication est fortement chargé, ou si vous avez lancé une commande STOP SLAVE.) Les informations de connexions stockées dans le fichier master.info reprennent immédiatement les valeurs spécifiées dans les options de démarrage, si elles étaient précisées. Ces informations incluent notamment le nom de l'hôte maître, le port, l'utilisateur et le mot de passe. Si le thread esclave était au milieu d'une réplication temporaire lorsqu'il a été arrêté, et que RESET SLAVE a été émise, ces tables temporaires sont aussi effacées.

Cette commande s'appelait FLUSH SLAVE avant MySQL 3.23.26.

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n

Ignore les n prochains événements du maître. C'est une commande pratique pour rattraper les arrêts de réplications causés par une commande.

Cette commande n'est valide que lorsque le thread esclave ne fonctionne pas. Sinon, elle produit une erreur.

Avant MySQL 4.0, omettez le mot clé GLOBAL dans la commande.

SHOW SLAVE STATUS

Affiche des informations sur les paramètres essentiels des threads esclaves. Si vous utilisez cette commande avec le client mysql, vous pouvez utiliser le terminateur de commande \G plutôt que le point-virgule pour avoir un format plus lisible :

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          Master_User: root
          Master_Port: 3306
        Connect_Retry: 3
      Master_Log_File: gbichot-bin.005
  Read_Master_Log_Pos: 79
       Relay_Log_File: gbichot-relay-bin.005
        Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_Do_DB:
  Replicate_Ignore_DB:
           Last_Errno: 0
           Last_Error:
         Skip_Counter: 0
  Exec_Master_Log_Pos: 79
      Relay_Log_Space: 552
      Until_Condition: None
       Until_Log_File:
        Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
      Master_SSL_Cert:
    Master_SSL_Cipher:
       Master_SSL_Key:
Seconds_Behind_Master: 8

Suivant votre version de MySQL, vous pourriez ne pas voir tous les champs qui sont dans cet exemple. Notamment, il y a plusieurs champs qui ne sont disponibles qu'avec MySQL 4.1.1.

Les champs affichés par SHOW SLAVE STATUS ont les définitions suivantes :

START SLAVE [thread_name [, thread_name] ... ]
START SLAVE [SQL_THREAD] UNTIL
    MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
START SLAVE [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos

thread_name = IO_THREAD | SQL_THREAD

START SLAVE, appelé sans option, démarre les deux threads esclaves. Le thread I/O lire les requêtes du maître et les stocke dans le log de relais. Le thread SQL lire le log de relais, et exécute les requêtes. Notez que si START SLAVE réussi à lancer le thread esclave, elle se terminera sans erreur. Mais même dans ce cas, il se peut que le thread esclave se lance, puis s'arrête (car il n'a pas pu se connecter au maître, ou lire le log binaire ou tout autre problème). START SLAVE ne vous préviendra pas de cet événement. Vous devez vérifier le log d'erreur de l'esclave pour voir si des messages ont été générés, ou encore vérifier que tout fonctionne avec la commande SHOW SLAVE STATUS.

Depuis MySQL 4.0.2, vous pouvez ajouter les options IO_THREAD ou SQL_THREAD à la commande, pour nommer les threads que vous lancez.

Depuis MySQL 4.1.1, une clause UNTIL peut être ajoutée pour spécifier que l'esclave doit commencer à un certain point dans le log binaire, ou dans le log de relais. Lorsque le thread SQL atteint ce point, il s'arrête. Si l'option SQL_THREAD est spécifiée dans la commande, seule le thread SQL est lancé. Sinon, les deux threads sont lancés. Si le thread SQL est déjà lancé, la clause UNTIL est ignorée, et une alerte est émise.

Avec la clause UNTIL, vous devez spécifier à la fois un fichier de log et une position. Ne confondez pas les options du maître et celles du log de relais.

Toute condition UNTIL est annulée par une commande STOP SLAVE, ou une commande START SLAVE qui n'inclut pas de condition UNTIL, ou encore un redémarrage serveur.

La clause UNTIL peut être utile pour déboguer la réplication, ou pour vous assurer que la réplication s'effectue jusqu'à un certain point. Par exemple, si une commande imprudente DROP TABLE a été exécutée sur le maître, vous pouvez utiliser la clause UNTIL pour dire à l'esclave de s'exécuter jusqu'à ce moment, puis de s'arrêter. Pour trouver cet événement, utilisez l'utilitaire mysqlbinlog sur le log du maître, ou sur le log de relais, ou encore utilisez la commande SHOW BINLOG EVENTS.

Si vous utilisez la clause UNTIL pour faire des réplications par portions, il est recommandé de lancer l'esclave avec l'option --skip-slave-start pour éviter que le thread SQL ne se lance lorsque l'esclave se lance. Il est probablement idéale d'utiliser cette option dans un fichier d'options plutôt qu'en ligne de commande, pour qu'un redémarrage intempestif ne l'oublie pas.

La commande SHOW SLAVE STATUS affiche un champ qui indique la valeur courante de la clause UNTIL.

STOP SLAVE [thread_name [, thread_name] ... ]

thread_name = IO_THREAD | SQL_THREAD

Arrête l'esclave. Tout comme START SLAVE, cette commande peut être utilisée avec les options IO_THREAD et SQL_THREAD pour identifier le thread par son nom.

Cette commande s'appelait SLAVE STOP avant MySQL 4.0.5. Actuellement, SLAVE STOP est toujours disponible pour assurer la compatibilité ascendante, mais c'est une commande abandonnée.