Manuel de référence MySQL 5.0

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

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 :

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é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.

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 :

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

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 écrits 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 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 :

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

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 :

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

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 :

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 peut ê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 :

• 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.

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 :

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 :

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

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 :

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 :

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 l'exception où vous ne pouvez pas utiliser une variable système structurée, là où une variable simple fonctionnerait.