Chapitre 9 Structure du langage

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.

'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 :

[_charset_name]'string' [COLLATE collation_name]

Exemples :

SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;

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

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

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. See Section 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 :

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

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 :

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

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

Exemples d'entiers valides :

1221
0
-32

Exemples de nombres à virgule flottante :

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.

MySQL supporte les valeurs hexadécimales. Dans un contexte numérique, elles agissent comme des entiers (précision 64-bit). 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 :

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

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() :

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

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

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

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 zéros et des uns.

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

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        |
+------+----------+----------+----------+

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. See Section 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). See Section 13.1.5, « Syntaxe de LOAD DATA INFILE ».

MySQL autorise l'utilisation de nom 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 :

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 ambigüe. 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 ‘.’.

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. See Section 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 casse 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 :

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 :

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 peuvent être spécifié au lancement de mysqld. lower_case_table_names peut prendre l'une des valeurs suivantes :

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 :

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.

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 :

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

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é sont utilisées comme exemple syntaxique, mais les détails concernant le cache de clé sont disponibles dans la section Section 7.4.6, « Le cache de clé 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 :

hot_cache.key_buffer_size
hot_cache.key_cache_block_size
cold_cache.key_cache_block_size

Pour chaque variables système structurée, un instance avec le nom default est toujours prédéfinie. Si vous faites référence à un composant d'une variables 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érences à 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 :

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éées dans le futur.

A 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 :

shell> mysqld --hot_cache.key_buffer_size=64K

Dans un fichier d'options, faites ceci :

[mysqld]
hot_cache.key_buffer_size=64K

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

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

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 buffer de 2096 octets.

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

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 lue durant l'exécution. Par exemple, pour créer un cache de clé appelé hot_cache, de taille 10 Mo, utilisez une des commandes suivantes :

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 :

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 :

mysql> SHOW GLOBAL VARIABLES LIKE 'hot_cache.key_buffer_size';

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