Manuel de référence MySQL 5.0


précédentsommairesuivant

9. Structure du langage

Ce chapitre présente les règles d'écriture des commandes SQL avec MySQL.

  • Les valeurs littérales telles que les nombres et chaînes.

  • Les identifiants de tables et colonnes.

  • Les variables utilisateur et système.

  • Les commentaires.

  • Les mots réservés.

9-1. Littéraux : comment écrire les chaînes et les nombres

Cette section décrit les différentes façons d'écrire les chaînes et les nombres en MySQL. Elle couvre aussi les différentes nuances et quiproquos que vous pouvez rencontrer lorsque vous manipulez ces types de données.

9-1-1. Chaînes

Une chaîne est une séquence de caractères, entourée de guillemets simples (''') ou doubles ('"'). Exemples :

Si le serveur SQL est en mode ANSI_QUOTES, les chaînes littérales ne peuvent être mises qu'entre guillemets simples. Une chaîne avec des guillemets double sera interprétée comme un identifiant.

 
Sélectionnez
'une chaîne'
"une autre chaîne"

Depuis MySQL 4.1.1, les littéraux disposent d'une option de jeu de caractères et de collation avec la clause COLLATE :

 
Sélectionnez
[_charset_name]'string' [COLLATE collation_name]

Exemples :

 
Sélectionnez
SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;

Pour plus d'informations sur ces formes de chaînes de caractères, voyez Section 10.3.7, « Jeu de caractères et collation des chaînes littérales »10.3.7. Jeu de caractères et collation des chaînes littérales.

À l'intérieur d'une chaîne, certaines séquences de caractères ont une signification spéciale. Chacune d'elles commence par un anti-slash ('\'), connu comme le caractère d'échappement. MySQL reconnaît les séquences suivantes :

\0 Un 0 ASCII (NUL).
\' Un guillemet simple (''').
\" Un guillemet double ('"').
\b Un effacement.
\n Une nouvelle ligne.
\r Un retour chariot.
\t Une tabulation.
\z ASCII(26) (Contrôle-Z). Ce caractère peut être encodé pour vous éviter des problèmes avec Windows, vu qu'il équivaut à une fin de fichier sur cet OS. (ASCII(26) vous posera des problèmes si vous utilisez mysql base < fichier.)
\\ Un anti-slash ('\').
\% Un signe pourcentage littéral : '%'. Voir les notes ci-dessous.
\_ Un signe souligné littéral : '_'. Voir les notes ci-dessous.

Ces séquences sont sensibles à la casse. Par exemple, '\b' est interprétée comme un anti-slash, mais '\B' est interprété comme la lettre 'B'.

Les caractères '\%' et '\_' sont utilisés pour rechercher des chaînes littérales '%' et '_' dans un contexte d'expressions régulières. Sinon, ces caractères sont interprétés comme des caractères joker. Voir Section 12.3.1, « Opérateurs de comparaison pour les chaînes de caractères »12.3.1. Opérateurs de comparaison pour les chaînes de caractères. Notez que si vous utilisez '\%' ou '\_' dans d'autres contextes, ces séquences retourneront '\%' et '\_' et non '%' et '_'.

Il y a plusieurs façons d'intégrer un guillemet dans une chaîne.

  • Un ''' à l'intérieur d'une chaîne entourée de ''' peut être noté ''''.

  • Un '"' à l'intérieur d'une chaîne entourée de '"' peut être noté '""'.

  • Vous pouvez faire précéder le guillemet par caractère d'échappement ('\').

  • Un guillemet simple ''' à l'intérieur d'une chaîne à guillemets doubles '"' n'a besoin d'aucun traitement spécial (ni doublage, ni échappement). De même, aucun traitement spécial n'est requis pour un guillemet double '"' à l'intérieur d'une chaîne à guillemets simples '''.

Le SELECT montré ici explique comment les guillemets et les échappements fonctionnent :

 
Sélectionnez
mysql> SELECT 'bonjour', '"bonjour"', '""bonjour""', 'bon''jour', '\'bonjour';
+---------+-----------+-------------+----------+----------+
| bonjour | "bonjour" | ""bonjour"" | bon'jour | 'bonjour |
+---------+-----------+-------------+----------+----------+

mysql> SELECT "bonjour", "'bonjour'", "''bonjour''", "bon""jour", "\"bonjour";
+---------+-----------+-------------+----------+----------+
| bonjour | 'bonjour' | ''bonjour'' | bon"jour | "bonjour |
+---------+-----------+-------------+----------+----------+

mysql> SELECT "Voilà\n3\nlignes";
+--------------------+
| Voilà
3
lignes |
+--------------------+

Si vous voulez insérer des données binaires dans un champ chaîne (comme un BLOB), les caractères suivants doivent être échappés :

NUL ASCII 0. Représentez-le avec '\0' (un anti-slash suivi du caractère ASCII '0').
\ ASCII 92, anti-slash. À représenter avec '\\'.
' ASCII 39, guillemet simple. À représenter avec '\''.
" ASCII 34, guillemet double. À représenter avec '\"'.

Lorsque vous écrivez des applications, toutes les chaînes qui risquent de contenir ces caractères spéciaux doivent être protégées avant d'être intégrées dans la commande SQL. Vous pouvez faire cela de deux manières différentes :

  • passez la chaîne à une fonction qui protège les caractères spéciaux. Par exemple, en langage C, vous pouvez utiliser la fonction mysql_real_escape_string(). Voir Section 24.2.3.47, « mysql_real_escape_string() »24.2.3.47. mysql_real_escape_string(). L'interface Perl DBI fournit une méthode basée sur les guillemets pour convertir les caractères spéciaux en leur séquence correspondante. Voir Section 24.4, « API Perl pour MySQL »24.4. API Perl pour MySQL ;

  • au lieu de protéger explicitement tous les caractères, de nombreuses interfaces MySQL fournissent un système de variables qui vous permettent de mettre des marqueurs dans la requête, et de lier les variables à leur valeur au moment de leur exécution. Dans ce cas, l'interface se charge de protéger les caractères spéciaux pour vous.

9-1-2. Nombres

Les entiers sont représentés comme une séquence de chiffres. Les décimaux utilisent '.' comme séparateur décimal. Tous les types de nombres peuvent être précédés d'un '-' pour indiquer une valeur négative.

Exemples d'entiers valides :

 
Sélectionnez
1221
0
-32

Exemples de nombres à virgule flottante :

 
Sélectionnez
294.42
-32032.6809e+10
148.00

Un entier peut être utilisé dans un contexte décimal, il sera interprété comme le nombre décimal équivalent.

9-1-3. Valeurs hexadécimales

MySQL supporte les valeurs hexadécimales. Dans un contexte numérique, elles agissent comme des entiers (précision 64 bits). Dans un contexte de chaîne, elles agissent comme une chaîne binaire où chaque paire de caractères hexadécimaux est convertie en caractère :

 
Sélectionnez
mysql> SELECT x'4D7953514C';
        -> 'MySQL'
mysql> SELECT 0xa+0;
        -> 10
mysql> SELECT 0x5061756c;
        -> 'Paul'

En MySQL 4.1 (et en MySQL 4.0 si vous utilisez l'option --new), le type par défaut d'une valeur hexadécimale est chaîne. Si vous voulez vous assurer qu'une telle valeur est traitée comme un nombre, vous pouvez utiliser CAST(... AS UNSIGNED) :

 
Sélectionnez
mysql> SELECT 0x41, CAST(0x41 AS UNSIGNED);
        -> 'A', 65

La syntaxe 0x est basée sur ODBC. Les chaînes hexadécimales sont souvent utilisées par ODBC pour fournir des valeurs aux colonnes BLOB. La syntaxe x'hexstring' est nouvelle en 4.0 et est basée sur le standard SQL.

Depuis MySQL 4.0.1, vous pouvez convertir une chaîne ou nombre en chaîne au format hexadécimal avec la fonction HEX() :

 
Sélectionnez
mysql> SELECT HEX('cat');
        -> '636174'
mysql> SELECT 0x636174;
        -> 'cat'

9-1-4. Valeurs booléennes

Depuis MySQL version 4.1, la constante TRUE vaut 1 et la constante FALSE vaut 0. Les noms des constantes peuvent être écrits en minuscules ou majuscules.

 
Sélectionnez
mysql> SELECT TRUE, true, FALSE, false;
        -> 1, 1, 0, 0

9-1-5. Champs de bits

Depuis MySQL 5.0.3, les champs de bits peuvent être écrits avec la notation b'value'. value est une valeur binaire écrite avec des 0 et des 1.

La notation en champ de bits est pratique pour spécifier des données qui doivent être assignées à une colonne de type BIT :

 
Sélectionnez
mysql> CREATE TABLE t (b BIT(8));
mysql> INSERT INTO t SET b = b'11111111';
mysql> INSERT INTO t SET b = b'1010';
+------+----------+----------+----------+
| b+0  | BIN(b+0) | OCT(b+0) | HEX(b+0) |
+------+----------+----------+----------+
|  255 | 11111111 | 377      | FF       |
|   10 | 1010     | 12       | A        |
+------+----------+----------+----------+

9-1-6. Valeurs NULL

La valeur NULL signifie « pas de données » et est différente des valeurs comme 0 pour les nombres ou la chaîne vide pour les types chaîne. Voir Section A.5.3, « Problèmes avec les valeurs NULL »A.5.3. Problèmes avec les valeurs NULL.

NULL peut être représenté par \N lors de la récupération ou écriture avec des fichiers (LOAD DATA INFILE, SELECT ... INTO OUTFILE). Voir Section 13.1.5, « Syntaxe de LOAD DATA INFILE »13.1.5. Syntaxe de LOAD DATA INFILE.

9-2. Noms de bases, tables, index, colonnes et alias

Les noms des bases de données, tables, index, colonnes et alias suivent tous les mêmes règles en MySQL.

La table suivante décrit la taille maximale et les caractères autorisées pour chaque type d'identifiant.

Identifiant Longueur maximale Caractères autorisés
Base de données 64 Tous les caractères autorisés dans un nom de dossier à part '/', '\' et '.'.
Table 64 Tous les caractères autorisés dans le nom d'un fichier à part '/' et '.'.
Colonne 64 Tous.
Index 64 Tous.
Alias 255 Tous.

Notez qu'en plus de ce qui précède, vous n'avez pas droit aux caractères ASCII(0) ou ASCII(255) dans un identifiant. Avant MySQL 4.1, les identifiants ne pouvaient pas contenir de guillemets.

Depuis MySQL 4.1, les identifiants sont stockés en Unicode (UTF8). Cela s'applique aux identifiants stockés dans les tables de définitions du fichier .frm, et aux identifiants stockés dans les tables de droits de la base mysql. Même si les identifiants Unicode peuvent inclure des caractères multioctets, notez que les tailles maximales affichées dans la table sont donnés en octets. Si un identifiant contient un caractère multioctet, le nombre de caractères autorisé est alors inférieur aux chiffres affichés.

Un identifiant peut être entre guillemets ou pas. Si un identifiant est un mot réservé, ou qu'il contient des caractères spéciaux, vous devez le mettre entre guillemets lorsque vous l'utilisez. Pour une liste des mots réservés, voyez Section 9.6, « Cas des mots réservés MySQL »9.6. Cas des mots réservés MySQL. Les caractères spéciaux sont hors de la plage des caractères alphanumérique et '_' et '$'.

Notez que si un identifiant est un mot réservé, ou contient des caractères spéciaux, vous devez absolument le protéger avec '`' :

Le caractère de protection des identifiants est le guillemet oblique '`' :

 
Sélectionnez
mysql> SELECT * FROM `select` WHERE `select`.id > 100;

Si vous utilisez MySQL avec les modes MAXDB ou ANSI_QUOTES, il est aussi possible d'utiliser les guillemets doubles pour les identifiants :

 
Sélectionnez
mysql> CREATE TABLE "test" (col INT);
ERROR 1064: You have an error in your SQL syntax. (...)
mysql> SET SQL_MODE="ANSI_QUOTES";
mysql> CREATE TABLE "test" (col INT);
Query OK, 0 rows affected (0.00 sec)

Voir Section 1.5.2, « Sélectionner les modes SQL »1.5.2. Sélectionner les modes SQL.

Depuis MySQL 4.1, les guillemets peuvent être inclus dans les noms d'identifiants. Si le caractère inclus dans l'identifiant est le même que celui qui est utilisé pour protéger l'identifiant, doublez-le. La commande suivante crée la table a`b, qui contient la colonne c"d :

 
Sélectionnez
mysql> CREATE TABLE `a``b` (`c"d` INT);

La protection d'identifiant par guillemets a été introduite en MySQL 3.23.6 pour permettre l'utilisation de mots réservés ou des caractères spéciaux dans les noms de colonnes. Avant la version 3.23.6, vous ne pouviez pas utiliser les identifiants qui utilisent des guillemets, et les règles sont plus restrictives.

Il est recommandé de ne pas utiliser de noms comme 1e, car une expression comme 1e+1 est ambigüe. Elle pourrait être interprétée comme l'expression 1e + 1 ou comme le nombre 1e+1, suivant le contexte.

9-2-1. Identifiants

MySQL autorise l'utilisation de noms qui sont constitués d'un seul identifiant, ou d'identifiants multiples. Les composants d'un tel nom doivent être séparés par le caractère point ('.'). Le premier composant détermine le contexte dans lequel l'identifiant final est interprété.

En MySQL, vous pouvez faire référence à une colonne en utilisant l'une des trois formes suivantes :

Référence de colonne Signification
col_name La colonne col_name de n'importe quelle table de la requête qui contient une colonne de ce nom.
tbl_name.col_name La colonne col_name de la table tbl_name de la base de données par défaut.
db_name.tbl_name.col_name La colonne col_name de la table tbl_name de la base db_name. Cette syntaxe n'est pas disponible avant MySQL version 3.22.

Si un composant d'un nom complexe requiert des guillemets de protection, vous devez protéger chaque composant individuellement plutôt que l'identifiant dans son ensemble. Par exemple, `my-table`.`my-column` est valide, mais `my-table.my-column` ne l'est pas.

Vous n'êtes pas obligé de spécifier le nom d'une table tbl_name ou le nom de la base db_name.tbl_name comme préfixe dans une requête, à moins que la référence soit ambiguë. Supposez que les tables t1 et t2 contiennent toutes les deux une colonne c, et que vous lisez le contenu de la colonne c dans une commande SELECT qui utilise les deux tables t1 et t2. Dans ce cas, c est ambigue, car ce n'est pas un nom unique dans les différentes tables de la commande. Vous devez le préciser avec un nom de table, comme dans t1.c ou t2.c. Similairement, si vous lisez des colonnes dans une table t de la base db1 et dans la table t de la base db2 dans la même commande, vous devez utiliser les noms complets de colonnes, comme db1.t.col_name et db2.t.col_name.

La syntaxe .tbl_name correspond à la table tbl_name de la base courante. Cette syntaxe est acceptée pour la compatibilité avec ODBC, car certains programmes ODBC préfixent le nom de la table avec un caractère point '.'.

9-2-2. Sensibilité à la casse pour les noms

En MySQL, les bases et les tables correspondent à des dossiers et des fichiers. Les tables dans une base correspondent au moins à un fichier dans le dossier de base et possiblement plusieurs, suivant le moteur de table utilisé. Par conséquent, la sensibilité à la casse du système déterminera la sensibilité à la casse des noms de bases de données et tables. Cela signifie que les noms sont insensibles à la casse sous Windows, et sensibles sous la plupart des variétés Unix. Mac OS X est une exception, car il est basé sur Unix, mais le système de fichiers par défaut (HFS+) n'est pas sensible à la casse. Cependant, Mac OS X supporte aussi les volumes UFS, qui sont sensibles à la casse, comme les autres Unix. Voir Section 1.5.4, « Extensions MySQL au standard SQL-92 »1.5.4. Extensions MySQL au standard SQL-92.

Note : même si les noms ne sont pas sensibles à la casse sous Windows, vous ne devez pas vous référer à une entité en utilisant différentes casses dans la même requête. La requête suivante ne fonctionnera pas, car elle se réfère à une table avec ma_table et MA_TABLE :

 
Sélectionnez
mysql> SELECT * FROM ma_table WHERE MA_TABLE.col=1;

Les noms de colonnes et d'alias sont insensibles à la casse dans tous les cas.

Les alias sur tables sont sensibles à la casse avant MySQL 4.1.1. La requête suivante ne marchera pas, car elle se réfère à a et A :

 
Sélectionnez
mysql> SELECT nom_de_colonne FROM nom_de_table AS a
    ->                 WHERE a.nom_de_colonne = 1 OR A.nom_de_colonne = 2;

Si vous avez du mal à vous souvenir de la casse des noms de bases et de tables, adoptez une convention, comme toujours créer les bases et les tables en utilisant des minuscules.

La façon de stocker les noms sur le disque et leur utilisation dans les syntaxes MySQL est définie par la variable lower_case_table_names, qui peut être spécifié au lancement de mysqld. lower_case_table_names peut prendre l'une des valeurs suivantes :

Valeur Signification
0 Les noms de tables et bases sont stockés sur le disque avec la casse utilisée dans la commande CREATE TABLE ou CREATE DATABASE. Les comparaisons de noms sont sensibles à la casse. C'est le comportement par défaut sous Unix. Notez que si vous forcez cette valeur à 0 avec l'option --lower-case-table-names=0 sur un système insensible à la casse, et que vous accéder à la table avec une autre casse, alors vous pouvez avoir des corruptions d'index.
1 Les noms de tables sont stockés en minuscules sur le disque, et les comparaisons de nom de tables sont insensibles à la casse. Ce comportement s'applique aussi aux noms de bases de données depuis MySQL 4.0.2, et aux alias de tables depuis 4.1.1. C'est la valeur par défaut sur les systèmes Windows et Mac OS X.
2 Les tables et bases sont stockés sur le disque avec la casse spécifiée dans CREATE TABLE et CREATE DATABASE, mais MySQL les convertit en minuscules lors des recherches. Les comparaisons de noms sont insensibles à la casse. Note : cela ne fonctionne que sur les systèmes de fichiers qui sont insensibles à la casse. Les noms de tables InnoDB sont stockés en minuscules, comme pour lower_case_table_names=1. Donne à lower_case_table_names la valeur de 2 est possible depuis MySQL 4.0.18.

Si vous utilisez MySQL sur une seule plate-forme, vous n'aurez pas à changer la valeur de lower_case_table_names variable. Cependant, vous pouvez rencontrer des problèmes lors des transferts entre plates-formes, où les systèmes de fichiers différent de par leur sensibilité à la casse. Par exemple, sous Unix, vous pouvez avoir deux tables ma_table et MA_TABLE, alors que sous Windows, ces deux noms représentent la même table. Pour éviter les problèmes de transferts de noms, vous avez deux choix :

  • utiliser l'option lower_case_table_names=1 sur tous les systèmes. L'inconvénient le plus sérieux est que lorsque vous utilisez SHOW TABLES ou SHOW DATABASES, vous ne verrez pas la casse originale des noms ;

  • utiliser lower_case_table_names=0 sous Unix et lower_case_table_names=2 sous Windows. Cela préserve la casse des noms de tables ou bases. L'inconvénient est que vous devez vous assurer que les requêtes utilisent toujours la bonne casse sous Windows. Si vous transférez vos requêtes vers Unix, où la casse des noms aura son importance, les requêtes ne fonctionneraient plus.

Notez qu'avant de passer la valeur de lower_case_table_names à 1 sous Unix, vous devez commencer par convertir vos anciens noms de tables et bases en minuscules, avant de redémarrer mysqld.

9-3. Variables utilisateur

MySQL supporte les variables utilisateur spécifiques à la connexion avec la syntaxe @variablename. Un nom de variable consiste en caractères alphanumériques, basés sur le jeu de caractères courant, de '_', '$', et '.'. Le jeu de caractères par défaut est ISO-8859-1 Latin1. Cette valeur peut être changée en utilisant l'option --default-character-set de mysqld. Voir Section 5.8.1, « Le jeu de caractères utilisé pour les données et le stockage »5.8.1. Le jeu de caractères utilisé pour les données et le stockage.

Les variables n'ont pas besoin d'être initialisés. Elles sont à NULL par défaut et peuvent contenir un entier, un réel ou une chaîne. Toutes les variables d'un thread sont automatiquement libérées lorsque le thread se termine.

Vous pouvez déclarer une variable avec la syntaxe de SET :

 
Sélectionnez
SET @variable= { expression entier | expression réel | expression chaîne }
[,@variable= ...].

Vous pouvez aussi assigner une valeur à une variable avec d'autres commandes que SET. Par contre, dans ce cas-là, l'opérateur d'assignation est := au lieu de =, parce que = est réservé aux comparaisons dans les requêtes autres que SET :

 
Sélectionnez
mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
+----------------------+------+------+------+
| @t1:=(@t2:=1)+@t3:=4 | @t1  | @t2  | @t3  |
+----------------------+------+------+------+
|                    5 |    5 |    1 |    4 |
+----------------------+------+------+------+

Les variables utilisateur peuvent être utilisées là où les expressions sont allouées. Notez que cela n'inclut pas pour l'instant les contextes où un nombre est explicitement requis, comme ce qui est le cas avec la clause LIMIT dans une requête SELECT, ou la clause IGNORE nombre LINES dans une requête LOAD DATA.

Note : dans une requête SELECT, chaque expression n'est évaluée que lors de l'envoi au client. Cela signifie que pour les clauses HAVING, GROUP BY, ou ORDER BY, vous ne pouvez vous référer à une expression qui implique des variables qui sont définies dans la partie SELECT. Par exemple, la requête suivante ne produira pas le résultat escompté :

 
Sélectionnez
mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM nom_de_table HAVING b=5;

La raison est que @aa ne contiendra pas la valeur de la ligne courante, mais celle de id pour la dernière ligne acceptée.

La règle générale est de ne jamais assigner et utiliser la même variable dans la même commande.

Un autre problème avec l'affectation de variable et son utilisation dans la même commande est que le type de valeur par défaut est basé sur le type de la variable dans la commande de départ. Une variable non assignée est supposée être de type NULL ou de type STRING. L'exemple suivant illustre bien ce cas de figure :

 
Sélectionnez
mysql> SET @a="test";
mysql> SELECT @a,(@a:=20) FROM table_name;

Dans ce cas, MySQL va indiquer au client que la colonne 1 est une chaîne, et il convertira tous les accès à la variable @a en chaîne, même si @a recevra finalement un nombre dans la seconde ligne. Après l'exécution de la commande, @a sera considéré comme un nombre.

Si vous avez des problèmes avec cela, essayer d'éviter d'affecter et d'utiliser la même variable dans la même commande, ou bien initialisez la variable avec les valeurs de 0, 0.0 ou "" avant de l'utiliser.

9-4. Variables système

À partir de la version 4.0.3, nous fournissons un meilleur accès à beaucoup de variables système et variables de connexion. On peut changer la plupart d'entre elles sans avoir à stopper le serveur.

Le serveur mysqld dispose de deux types de variables. Les variables globales, qui affectent l'ensemble du serveur. Les variables de session qui affectent des connexions individuelles.

Lorsque mysqld démarre, toutes les variables globales sont initialisées à partir des arguments passés en ligne de commande et des fichiers de configuration. Vous pouvez changer ces valeurs avec la commande SET GLOBAL. Lorsqu'un nouveau thread est créé, les variables spécifiques aux threads sont initialisées à partir des variables globales et ne changeront pas même si vous utilisez la commande SET GLOBAL.

Le serveur entretient aussi un jeu de variables de session pour chaque client qui se connecte. Les variables de session d'un client sont initialisées au moment de la connexion, en utilisant les valeurs correspondantes globales. Pour les variables de session qui sont dynamiques, le client peut les changer avec la commande SET SESSION var_name. Modifier les variables de session d'une connexion ne requiert aucun droit spécifique, mais le client ne peut changer que ses propres variables de session, et non pas celles d'un autre client.

Une modification à une variable globale est visible à tous les clients qui accèdent à cette variable. Mais, cela n'affecte la variable de session correspondante que lors de la prochaine connexion. Les connexions déjà établies ne sont pas affectées par un changement de variable globale. (Pas même le client qui a émis la commande SET GLOBAL.)

Pour définir la valeur d'une variable GLOBAL, vous devez utiliser l'une des syntaxes suivantes. Ici nous utilisons la variable sort_buffer_size à titre d'exemple.

Pour donner la valeur à une variable GLOBAL, utilisez l'une de ces syntaxes :

 
Sélectionnez
mysql> SET GLOBAL sort_buffer_size=value;
mysql> SET @@global.sort_buffer_size=value;

Pour définir la valeur d'une variable SESSION, vous devez utiliser l'une des syntaxes suivantes :

 
Sélectionnez
mysql> SET SESSION sort_buffer_size=value;
mysql> SET @@session.sort_buffer_size=value;
mysql> SET sort_buffer_size=value;

LOCAL est un synonyme de SESSION.

Si vous ne spécifiez pas GLOBAL ou SESSION alors SESSION est utilisé. Voir Section 13.5.2.8, « Syntaxe de SET »13.5.2.8. Syntaxe de SET.

Pour récupérer la valeur d'une variable de type GLOBAL vous pouvez utiliser l'une des commandes suivantes :

 
Sélectionnez
mysql> SELECT @@global.sort_buffer_size;
mysql> SHOW GLOBAL VARIABLES like 'sort_buffer_size';

Pour récupérer la valeur d'une variable de type SESSION vous pouvez utiliser l'une des commandes suivantes :

 
Sélectionnez
mysql> SELECT @@sort_buffer_size;
mysql> SELECT @@session.sort_buffer_size;
mysql> SHOW SESSION VARIABLES like 'sort_buffer_size';

Ici aussi, LOCAL est un synonyme de SESSION.

Lorsque vous récupérez une valeur de variable avec la syntaxe @@nom_variable et que vous ne spécifiez pas GLOBAL ou SESSION, MySQL retournera la valeur spécifique au thread (SESSION) si elle existe. Sinon, MySQL retournera la valeur globale.

Pour la commande SHOW VARIABLES, si vous ne spécifiez pas GLOBAL, SESSION ou LOCAL, MySQL retourne les valeurs de SESSION.

La raison d'imposer la présence du mot GLOBAL pour configurer une variable de type GLOBAL mais non pour la lire est pour être sûr que vous n'aurez pas de problèmes plus tard si vous voulez introduire ou effacer une variable spécifique au thread qui aurait le même nom. Dans ce cas, vous pourriez changer accidentellement l'état du serveur pour toutes les connexions (et non la vôtre uniquement).

Plus d'informations sur les options de démarrage du système et les variables système sont dans les sections Section 5.2.1, « Options de ligne de commande de mysqld »5.2.1. Options de ligne de commande de mysqld et Section 5.2.3, « Variables serveur système »5.2.3. Variables serveur système. Une liste des variables qui peuvent être modifiées durant l'exécution est présentée dans Section 5.2.3.1, « Variables système dynamiques »5.2.3.1. Variables système dynamiques.

9-4-1. Variables système structurées

Les variables système structurées sont supportées depuis MySQL 4.1.1. Une variable structurée diffère d'une variable système classique sur deux points :

  • sa valeur est une structure avec des composants qui spécifient des paramètres serveur qui sont étroitement liés ;

  • il peut y avoir plusieurs instances d'une même variable système structurée. Chacune d'entre elles a un nom différent, et fait référence à une ressource différente, gérée sur le serveur.

Actuellement, MySQL supporte un type de variables système structurées. Il spécifie les paramètres qui gouvernent les caches de clés. Une variable système structurée de cache de clés contient les composants suivants :

  • key_buffer_size ;
  • key_cache_block_size ;
  • key_cache_division_limit ;
  • key_cache_age_threshold.

L'objectif de cette section est de décrire la syntaxe d'opération avec les variables système structurées. Les variables du cache de clés sont utilisées comme exemple syntaxique, mais les détails concernant le cache de clés sont disponibles dans la section Section 7.4.6, « Le cache de clés des tables MyISAM »7.4.6. Le cache de clés des tables MyISAM.

Pour faire référence à un composant d'une variable système structurée, vous pouvez utiliser un nom composé, au format nom_d_instance.nom_du_composant. Par exemple :

 
Sélectionnez
hot_cache.key_buffer_size
hot_cache.key_cache_block_size
cold_cache.key_cache_block_size

Pour chaque variable système structurée, une instance avec le nom default est toujours prédéfinie. Si vous faites référence à un composant d'une variable système structurée sans aucun nom d'instance, l'instance default sera utilisée. Par conséquent, default.key_buffer_size et key_buffer_size font référence à la même variable système structurée.

Les règles de nommage pour les variables système structurées et ses composants sont les suivantes.

  • Pour un type donné de variables système structurées, chaque instance doit avoir un nom unique à l'intérieur de ce type. Cependant, les noms d'instances doivent être uniques à l'intérieur des types de variables système structurées. Par exemple, chaque variable système structurée aura une instance default, ce qui fait que default n'est pas unique à l'intérieur des types de variables.

  • Les noms de composants de chaque variable système structurée doit être unique à travers tous les noms de variables système. Si ce n'était pas vrai (c'est-à-dire, si deux types de variables structurées pouvaient partager des noms de composants), il ne serait pas facile de trouver la variable structurée par défaut, pour ce type.

  • Si un nom de variable système structurée n'est pas valide en tant qu'identifiant non protégé, il faut utiliser les guillemets obliques pour le protéger. Par exemple, hot-cache n'est pas valide, mais `hot-cache` l'est.

  • global, session, et local ne sont pas des noms de composants valides. Cela évite les conflits avec des notations comme @@global.var_name, qui fait référence à des variables système non structurées.

Actuellement, les deux premières règles ne peuvent pas être violées, puisqu'il n'y a qu'un seul type de variables système structurées, celui des caches de clés. Ces règles prendront leur importance si d'autres types de variables structurées sont créés dans le futur.

À une exception près, il est possible de faire référence à une variable système structurée en utilisant des noms composés, dans un contexte où un nom de variable simple est utilisé. Par exemple, vous pouvez assigner une valeur à une variable structurée en utilisant la ligne de commande suivante :

 
Sélectionnez
shell> mysqld --hot_cache.key_buffer_size=64K

Dans un fichier d'options, faites ceci :

 
Sélectionnez
[mysqld]
hot_cache.key_buffer_size=64K

Si vous lancez le serveur avec cette option, il va créer un cache de clés appelé hot_cache, avec une taille de 64 ko, en plus du cache de clés par défaut, qui a une taille de 8 Mo.

Supposez que vous démarriez le serveur avec ces options :

 
Sélectionnez
shell> mysqld --key_buffer_size=256K \
         --extra_cache.key_buffer_size=128K \
         --extra_cache.key_cache_block_size=2096

Dans ce cas, le serveur utilise une taille par défaut de 256 ko pour le cache. Vous pourriez aussi écrire --default.key_buffer_size=256K. De plus, le serveur crée un second cache de clé appelé extra_cache, de taille 128 ko, avec une taille de bloc de buffers de 2096 octets.

L'exemple suivant démarre le serveur avec trois caches de clés différents, avec des tailles de ratio 3:1:1 :

 
Sélectionnez
shell> mysqld --key_buffer_size=6M \
         --hot_cache.key_buffer_size=2M \
         --cold_cache.key_buffer_size=2M

Les variables système structurées peuvent être affectées et lues durant l'exécution. Par exemple, pour créer un cache de clés appelé hot_cache, de taille 10 Mo, utilisez une des commandes suivantes :

 
Sélectionnez
mysql> SET GLOBAL hot_cache.key_buffer_size = 10*1024*1024;
mysql> SET @@global.hot_cache.key_buffer_size = 10*1024*1024;

Pour lire la taille du cache, faites ceci :

 
Sélectionnez
mysql> SELECT @@global.hot_cache.key_buffer_size;

Cependant, la commande suivante ne fonctionne pas. La variable n'est pas interprétée comme un nom composé, mais comme une simple chaîne pour l'opérateur LIKE :

 
Sélectionnez
mysql> SHOW GLOBAL VARIABLES LIKE 'hot_cache.key_buffer_size';

C'est l'exception où vous ne pouvez pas utiliser une variable système structurée, là où une variable simple fonctionnerait.

9-5. Syntaxe des commentaires

Le serveur MySQL supporte trois types de commentaires :

  • depuis '#' jusqu'à la fin de la ligne ;

  • depuis '--' jusqu'à la fin de la ligne. Ce style est supporté depuis MySQL 3.23.3. Notez que le commentaire '--' (double-tiret) requiert que le second tiret soit suivi d'un espace ou par un autre caractère de contrôle comme une nouvelle ligne. Cette syntaxe diffère légèrement des standards SQL, comme discuté dans la section Section 1.5.5.7, « '--' comme début de commentaire »1.5.5.7. '--' comme début de commentaire ;

  • depuis '/*' jusqu'à '*/'. La séquence de fermeture n'a pas besoin d'être sur la même ligne, ce qui permet de répartir le commentaire sur plusieurs lignes.

Voici un exemple avec les trois types de commentaires :

 
Sélectionnez
mysql> SELECT 1+1;     # Ce commentaire se continue jusqu'à la fin de la ligne
mysql> SELECT 1+1;     -- Ce commentaire se continue jusqu'à la fin de la ligne
mysql> SELECT 1 /* Ceci est un commentaire dans la ligne */ + 1;
mysql> SELECT 1+
/*
Ceci est un commentaire
sur plusieurs lignes
*/
1;

La syntaxe des commentaires décrite ici s'applique à l'analyseur du serveur mysqld, lorsqu'il traite les commandes SQL. Le client mysql peut aussi effectuer des analyses de commandes avant de les envoyer : par exemple, il recherche les limites de requêtes dans les commandes multilignes. Cependant, il y a des limitations dans la façon de gérer les commentaires /* ... */.

  • Les guillemets (simples et doubles) sont considérés comme des indications de début de chaîne, même dans un commentaire. Si le guillemet n'est pas refermé (par un second guillemet), l'analyseur ne réalisera pas que le commentaire est fini. Si vous utilisez mysql interactivement, vous pouvez vous en apercevoir, car il va modifier l'invite de commande de mysql> en '> ou ">.

  • Un point-virgule sert à indiquer la fin de la commande SQL, et tout ce qui suit un point-virgule est considéré comme étant une nouvelle requête.

Ces limitations s'appliquent aussi bien à mysql en ligne de commande, que lorsque vous demandez à mysql de lire des commandes depuis un fichier (mysql < un-fichier).

9-6. Cas des mots réservés MySQL

Un problème récurrent provient de la tentative de création de tables avec des noms de colonnes qui sont des types de champs ou des fonctions natives de MySQL, comme TIMESTAMP ou GROUP. Il vous est permis de le faire (par exemple ABS est permis comme nom de colonne), mais les espaces ne sont pas permis entre le nom d'une fonction et la première '(' suivante lors de l'utilisation de fonctions qui sont aussi des noms de colonnes.

Un effet secondaire de ce comportement est que l'omission d'espace dans certains contexte fait que l'identifiant est interprété comme un nom de fonction. Par exemple, cette commande est valide :

 
Sélectionnez
mysql> CREATE TABLE abs (val INT);

Mais omettre l'espace après abs génère une erreur de syntaxe, car la commande semble utiliser la fonction ABS() :

 
Sélectionnez
mysql> CREATE TABLE abs(val INT);

Si vous lancez le serveur l'option de mode IGNORE_SPACE, le serveur autorisera l'appel de fonction avec un espace entre le nom de la fonction et le caractère de parenthèse ouvrante '(' suivant. Les noms de fonctions sont alors considérés comme des mots réservés. Comme pour les résultats, les noms de colonnes qui sont identiques au nom de fonctions doivent être placés entre guillemets, tels que décrit dans Section 9.2, « Noms de bases, tables, index, colonnes et alias »9.2. Noms de bases, tables, index, colonnes et alias. Le mode SQL du serveur est contrôlé par la procédure de la section Section 1.5.2, « Sélectionner les modes SQL »1.5.2. Sélectionner les modes SQL.

Les mots suivants sont explicitement réservés en MySQL. La plupart sont interdits par ANSI SQL92 en tant que nom de colonnes ou de tables (par exemple, GROUP). Quelques uns sont réservés parce que MySQL en a besoin et utilise (actuellement) un analyseur yacc :

ADD ALL ALTER
ANALYZE AND AS
ASC ASENSITIVE BEFORE
BETWEEN BIGINT BINARY
BLOB BOTH BY
CALL CASCADE CASE
CHANGE CHAR CHARACTER
CHECK COLLATE COLUMN
CONDITION CONNECTION CONSTRAINT
CONTINUE CONVERT CREATE
CROSS CURRENT_DATE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER CURSOR
DATABASE DATABASES DAY_HOUR
DAY_MICROSECOND DAY_MINUTE DAY_SECOND
DEC DECIMAL DECLARE
DEFAULT DELAYED DELETE
DESC DESCRIBE DETERMINISTIC
DISTINCT DISTINCTROW DIV
DOUBLE DROP DUAL
EACH ELSE ELSEIF
ENCLOSED ESCAPED EXISTS
EXIT EXPLAIN FALSE
FETCH FLOAT FLOAT4
FLOAT8 FOR FORCE
FOREIGN FROM FULLTEXT
GOTO GRANT GROUP
HAVING HIGH_PRIORITY HOUR_MICROSECOND
HOUR_MINUTE HOUR_SECOND IF
IGNORE IN INDEX
INFILE INNER INOUT
INSENSITIVE INSERT INT
INT1 INT2 INT3
INT4 INT8 INTEGER
INTERVAL INTO IS
ITERATE JOIN KEY
KEYS KILL LABEL
LEADING LEAVE LEFT
LIKE LIMIT LINES
LOAD LOCALTIME LOCALTIMESTAMP
LOCK LONG LONGBLOB
LONGTEXT LOOP LOW_PRIORITY
MATCH MEDIUMBLOB MEDIUMINT
MEDIUMTEXT MIDDLEINT MINUTE_MICROSECOND
MINUTE_SECOND MOD MODIFIES
NATURAL NOT NO_WRITE_TO_BINLOG
NULL NUMERIC ON
OPTIMIZE OPTION OPTIONALLY
OR ORDER OUT
OUTER OUTFILE PRECISION
PRIMARY PROCEDURE PURGE
RAID0 READ READS
REAL REFERENCES REGEXP
RELEASE RENAME REPEAT
REPLACE REQUIRE RESTRICT
RETURN REVOKE RIGHT
RLIKE SCHEMA SCHEMAS
SECOND_MICROSECOND SELECT SENSITIVE
SEPARATOR SET SHOW
SMALLINT SONAME SPATIAL
SPECIFIC SQL SQLEXCEPTION
SQLSTATE SQLWARNING SQL_BIG_RESULT
SQL_CALC_FOUND_ROWS SQL_SMALL_RESULT SSL
STARTING STRAIGHT_JOIN TABLE
TERMINATED THEN TINYBLOB
TINYINT TINYTEXT TO
TRAILING TRIGGER TRUE
UNDO UNION UNIQUE
UNLOCK UNSIGNED UPDATE
USAGE USE USING
UTC_DATE UTC_TIME UTC_TIMESTAMP
VALUES VARBINARY VARCHAR
VARCHARACTER VARYING WHEN
WHERE WHILE WITH
WRITE X509 XOR
YEAR_MONTH ZEROFILL  

Les symboles suivants (issus de la table ci-dessus) sont interdits par ANSI SQL, mais permis par MySQL en tant que noms de colonnes ou de tables. Cela est dû au fait que ces noms sont très courants, et de nombreux programmeurs les ont déjà utilisés.

  • ACTION

  • BIT

  • DATE

  • ENUM

  • NO

  • TEXT

  • TIME

  • TIMESTAMP


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+