Chapitre 1 Informations générales

Table des matières

1.1 A propos du manuel
1.1.1 Conventions utilisées dans ce manuel
1.2 Présentation du système de bases de données MySQL
1.2.1 Histoire de MySQL
1.2.2 Les fonctionnalités principales de MySQL
1.2.3 Jusqu'à quel point MySQL est il stable ?
1.2.4 Quelles tailles peuvent atteindre les tables MySQL
1.2.5 Compatibilité an 2000
1.3 Plan de développement de MySQL
1.3.1 MySQL 4.0 en bref
1.3.2 MySQL 4.1 en bref
1.3.3 MySQL 5.0, les prochains développements
1.4 Sources d'informations MySQL
1.4.1 Listes de diffusion MySQL
1.4.2 Support de la communauté MySQL sur IRC (Internet Relay Chat)
1.4.3 Support de la communauté MySQL sur les forums MySQL
1.5 Quels standards respecte MySQL ?
1.5.1 Quels standards suit MySQL ?
1.5.2 Sélectionner les modes SQL
1.5.3 Exécuter MySQL en mode ANSI
1.5.4 Extensions MySQL au standard SQL-92
1.5.5 Différences entre MySQL et le standard SQL-92
1.5.6 Comment MySQL gère les contraintes
1.5.7 Erreurs connues, et limitations de MySQL

Le logiciel MySQL (TM) est un serveur de base de données SQL très rapide, multi-threadé, multi-utilisateur et robuste. Le serveur MySQL est destiné aux missions stratégiques et aux systèmes de production à forte charge, ainsi qu'à l'intégration dans des logiciels déployés à grande échelle. MySQL est une marque déposée de MySQL AB.

Le logiciel MySQL dispose de deux licenses. Les utilisateurs peuvent choisir entre utiliser MySQL comme un logiciel Open Source/Logiciel libre, sous les termes de la licence GNU General Public License (http://www.gnu.org/licenses/) ou bien, ils peuvent acheter une licence commerciale auprès de MySQL AB. Voyez http://www.mysql.com/company/legal/licensing/ pour plus d'informations sur les licences.

Le site web de MySQL (http://www.mysql.com/) fournit les dernières informations sur le serveur MySQL.

La liste suivante décrit les sections particulières de ce manuel :

Important :

Les rapports d'erreurs (aussi appelés bogues), ainsi que les questions et commentaires, doivent être envoyés à la liste de diffusion générale. See Section 1.4.1.1, « Les listes de diffusion de MySQL ». See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».

Le script mysqlbug doit être utilisé pour générer le rapport de bogues. (Les distributions Windows contiennent un fichier mysqlbug.txt dans le dossier racine qui peut être utilisé comme formulaire pour un rapport de bug).

Pour les distributions sources, le script mysqlbug est accessible dans le dossier scripts. Pour les distributions binaires, mysqlbug est installé dans le dossier bin (/usr/bin pour le paquet RPM du serveur MySQL).

Si vous avez trouvé un problème de sécurité critique dans le code du serveur MySQL, vous devez envoyez un email à .

1.1 A propos du manuel

Ceci est le manuel de référence de MySQL; il documente MySQL jusqu'à la version 5.0.6-beta. Les évolutions fonctionnelles sont toujours indiquées avec une référence à la version d'évolution, de manière à ce que ce manuel soit toujours valable, même si vous utilisez une ancienne version de MySQL. Etant un manuel de référence, il ne fournit aucune description générale sur le langage SQL ou les concepts de bases de données relationnelles.

Comme le logiciel de base de données MySQL est en développement constant, ce manuel es mis à jour fréquemment. La version la plus récente est disponibles à http://dev.mysql.com/doc/ en différents formats, incluant HTML, PDF et Windows HLP.

L'original du document est un fichier au format Texinfo. La version HTML est produite automatiquement avec une version modifiée de texi2html. La version en texte plein et version Info sont produites par makeinfo. La version PostScript est produite avec texi2dvi et dvips. La version PDF est produite avec pdftex.

Si vous avez du mal à trouver des informations dans ce manuel, vous pouvez essayer notre version avec moteur de recherche, sur notre site web : http://www.mysql.com/doc/.

Si vous avez des suggestions concernant des ajouts ou des corrections à ce manuel, vous pouvez les envoyez à l'équipe de documentation à http://www.mysql.com/company/contact/.

Ce manuel a été écrit initialement par David Axmark et Michael ``Monty'' Widenius. Il est actuellement entretenu par l'équipe de documentation MySQL, constituée de Paul DuBois, Stefan Hinz, Mike Hillyer, Jon Stephens et Russell Dyer. Pour les autres contributeurs, voyez les Annexe B, Crédits.

La traduction de ce manuel a été faite sous la direction de Damien Séguy. Mehdi Achour, Patrick Haond, David Manusset, Sylvain Maugiron, Guillaume Plessis et Yannick Torres ont contribué largement à cette traduction.

Le copyright (2002-2006) de ce manuel est la propriété de la société suédoise MySQL AB.

1.1.1 Conventions utilisées dans ce manuel

Ce manuel utilise certaines conventions typographiques :

  • constant

    La police à largeur fixe est utilisée pour les noms de commandes et les options, les requêtes SQL, les noms de bases de données, de tables et de colonnes, le code C et Perl, les variables d'environnement. Par exemple, ``Pour voir comment mysqladmin fonctionne, exécutez-le avec l'option --help.''

  • filename

    La police à largeur fixe avec des guillemets d'encadrement indique des noms de fichiers et de chemins de dossiers. Par exemple : ``La distribution est installée dans le dossier /usr/local/.''

  • c

    La police à largeur fixe avec des guillemets d'encadrement est aussi utilisée pour indiquer des séquences de caractères. Par exemple : ``Pour spécifier un caractère joker, utilisez le caractère ‘%’.''

  • italique

    Les polices en italique sont utilisées pour attirer l'attention, comme ceci.

  • gras

    Le gras est utilisé pour les entêtes de tables, et aussi pour attirer fortement votre attention.

Lorsque les commandes qui sont affichées sont destinées à être exécutées par un programme particulier, le nom du programme est indiqué dans l'invite de la commande. Par exemple, shell> indique une commande que vous exécutez depuis votre console Shell, et mysql> indique une commande que vous exécutez depuis le client mysql :

shell> tapez une commande shell ici
mysql> tapez une requête SQL ici

Le ``Shell'' est votre interpréteur de ligne de commande. Sous Unix, c'est typiquement un programme comme sh ou csh. Sous Windows, le programme équivalent est command.com ou cmd.exe, typiquement utilisée en console.

Lorsque vous saisissez une commande dans un exemple, omettez simplement de saisir l'invite de commande affichée.

Souvent, les noms de bases de données, tables ou colonnes doivent être remplacés dans les commandes. Pour indiquer qu'une telle substitution est nécessaire, ce manuel utilise les noms de nom_de_base, nom_de_table et nom_colonne. Par exemple, vous pourriez avoir une requête comme ceci :

mysql> SELECT nom_colonne FROM nom_de_base.nom_de_table;

Cela signifie que si vous devez saisir une requête semblable, vous devriez utiliser votre propre nom de colonne, table et base de données, ce qui pourrait se traduire par ceci :

mysql> SELECT author_name FROM biblio_db.author_list;

Les mot réservés SQL ne sont pas sensibles à la casse, et peuvent être écrits en majuscules ou minuscules. Ce manuel utilise les majuscules.

Dans les illustrations de syntaxe, les crochets (‘[’ et ‘]’) sont utilisés pour indiquer des clauses ou mots optionnels. Par exemple, dans la requête suivante, IF EXISTS est optionnel :

DROP TABLE [IF EXISTS] nom_de_table

Lorsqu'un élément de syntaxe est constitué d'un certain nombre d'alternatives, les alternatives sont séparées par des barres verticales (‘|’). Lorsqu'un membre d'un tel jeu de possibilités peut être choisi, les alternatives sont listées entre crochets (‘[’ et ‘]’) :

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

Lorsqu'un élément d'un jeu de possibilités doit être choisi, les alternatives sont placées entre accolades (‘{’ et ‘}’) :

{DESCRIBE | DESC} nom_de_table {nom_colonne | wild}

Des crochets peuvent aussi indiquer que l'élément syntaxique précédent peut être répété. Dans l'exemple suivant, plusieurs valeurs reset_option peuvent être donnés, séparées par des virgules :

RESET reset_option [,reset_option] ...

Les commandes d'assignation des variables de Shell sont présentées avec la syntaxe Bourne Shell. Par exemple, la syntaxe suivante modifie une variable d'environnement :

shell> VARNAME=value some_command

Si vous utilisez csh ou tcsh, vous devez utiliser une syntaxe légèrement différente. Il faut écrire :

shell> setenv VARNAME value
shell> some_command

1.2 Présentation du système de bases de données MySQL

MySQL, le plus populaire des serveurs de bases de données SQL Open Source, est développé, distribué et supporté par MySQL AB. MySQL AB est une société commerciale, fondée par les développeurs de MySQL, qui développent leur activité en fournissant des services autour de MySQL.

Le site web de MySQL (http://www.mysql.com/) fournit les toutes dernières actualités sur le logiciel MySQL et sur la société MySQL AB.

  • MySQL est un système de gestion de bases de données.

    Une base de données est un ensemble organisé de données. Cela peut aller d'une simple liste de courses au supermarché à une galerie de photos, ou encore les grands systèmes d'informations des multi-nationales. Pour ajouter, lire et traiter des données dans une base de données, vous avez besoin d'un système de gestion de bases de données tel que le serveur MySQL. Comme les ordinateurs sont très bons à manipuler de grandes quantités de données, le système de gestion de bases de données joue un rôle central en informatique, aussi bien en tant qu'application à part entière, qu'intégré dans d'autres logiciels.

  • MySQL est un serveur de bases de données relationnelles.

    Un serveur de bases de données stocke les données dans des tables séparées plutôt que de tout rassembler dans une seule table. Cela améliore la rapidité et la souplesse de l'ensemble. Les tables sont reliées par des relations définies, qui rendent possible la combinaison de données entre plusieurs tables durant une requête. Le SQL dans ``MySQL'' signifie ``Structured Query Language'' : le langage standard pour les traitements de bases de données.

  • MySQL est Open Source.

    Open Source (Standard Ouvert) signifie qu'il est possible à chacun d'utiliser et de modifier le logiciel. Tout le monde peut télécharger MySQL sur Internet, et l'utiliser sans payer aucun droit. Toute personne en ayant la volonté peut étudier et modifier le code source pour l'adapter à ses besoins propres. Le logiciel MySQL utilise la licence GPL (GNU General Public License), http://www.gnu.org/licenses/, pour définir ce que vous pouvez et ne pouvez pas faire avec ce logiciel, dans différentes situations. Si vous ne vous sentez pas confortable avec la licence GPL ou bien que vous devez intégrer MySQL dans une application commerciale, vous pouvez acheter une licence commerciale auprès de MySQL AB.

  • Le serveur de bases de données MySQL est très rapide, fiable

    et facile à utiliser

    Si c'est ce que vous recherchez, vous devriez faire un essai. Le serveur de bases de données MySQL dispose aussi de fonctionnalités pratiques, développées en coopération avec nos utilisateurs. Vous pouvez trouver une comparaison des performances du serveur MySQL avec d'autres systèmes de bases de données dans nos pages de tests de performances. See Section 7.1.4, « La suite de tests MySQL ».

    Le serveur MySQL a été développé à l'origine pour gérer de grandes bases de données plus rapidement que les solutions existantes, et a été utilisé avec succès dans des environnements de production très contraintes et très exigeants, depuis plusieurs années. Bien que toujours en développement, le Le serveur MySQL offre des fonctions nombreuses et puissantes. Ses possibilités de connexions, sa rapidité et sa sécurité font du serveur MySQL une serveur hautement adapté à Internet.

  • MySQL Server fonctionne en mode client/serveur ou en

    système embarqué.

    Le serveur MySQL est un système client / serveur qui est constitué d'un serveur SQL multi-threadé qui supporte différentes interfaces, clients, bibliothèques et outils d'administration, ainsi qu'une large gamme de pilotes pour différents langages (API).

    Nous proposons aussi le serveur MySQL comme une bibliothèque embarquée, que vous pouvez intégrer dans vos applications pour en faire des produits plus petits, plus rapides et plus simples à utiliser.

  • Il existe un grand nombre de contributions à MySQL.

    Il est très probable que vous pourrez trouver votre éditeur préféré ou que votre environnement de programmation supporte déjà le serveur de base de données MySQL.

La prononciation officielle de MySQL est ``My Ess Que Ell'' (en anglais), ce qui donne ``Maille Esse Cu Elle'' en phonétique fran¸aise. Evitez d'utiliser la prononciation ``my sequel'', mais nous ne nous formaliserons pas que vous utilisiez ``my sequel'' (ma séquelle, en fran¸ais) ou une autre prononciation adaptée.

1.2.1 Histoire de MySQL

Nous avons débuté avec l'intention d'utiliser mSQL pour se connecter à nos tables en utilisant nos propres routines bas niveau ISAM. Cependant, après quelques tests, nous sommes arrivés à la conclusion que mSQL n'était pas assez rapide et flexible pour nos besoins. Cela nous a conduit à créer une nouvelle interface SQL pour notre base de données, mais en gardant la même API que mSQL. Cette API a été choisie pour la facilité de port des programmes de tiers.

Les liens avec le nom MySQL ne sont pas parfaitement établis. Notre dossier de base et un grand nombre de bibliothèques et outils étaient préfixés par ``my'' depuis plus de 10 ans. Mais la fille de Monty, plus jeune que lui, était aussi appelée My. Lequel des deux a conduit au nom de MySQL est toujours un mystère, même pour nous.

Le nom du dauphin MySQL (notre logo) est Sakila, qui a été choisi par les fondateurs de MySQL AB à partir d'une grande liste de noms suggérés par les utilisateurs dans le concours "Name the Dolphin" ("Nommez le dauphin"). Le nom a été suggéré par Ambrose Twebaze, un développeur de logiciels libres au Swaziland, en Afrique. D'après Ambrose, le nom Sakila puise ses origines du SiSwati, la langue locale du Swaziland. Sakila est aussi le nom d'une ville en Arusha, Tanzanie, près du pays d'origine d'Ambrose, Uganda.

1.2.2 Les fonctionnalités principales de MySQL

La liste suivante décrit les caractéristiques principales du logiciel de bases de données MySQL. Voyez la Section 1.3, « Plan de développement de MySQL » pour plus d'informations sur les fonctionnalités courantes et à venir.

  • Interne et portabilité

    • Ecrit en C et C++.

    • Testé sur un large éventail de compilateurs différents.

    • Fonctionne sur de nombreuses plates-formes. See Section 2.1.1, « Systèmes d'exploitation supportés par MySQL ».

    • Utilise GNU Automake, Autoconf et Libtool pour une meilleure portabilité.

    • Dispose d'API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl. See Chapitre 24, API MySQL.

    • Complètement multi-threadé, grâce aux threads du noyau. Cela signifie que vous pouvez l'utiliser facilement sur un serveur avec plusieurs processeurs.

    • Fournit des moteurs de tables transactionnels et non-transactionnels.

    • Index B-tree très rapide, avec compression d'index.

    • Facilité relative à ajouter un nouveau moteur de table. C'est utile si vous voulez ajouter une interface SQL à votre base de donnée maison.

    • Système l'allocation mémoire très rapide, exploitant les threads.

    • Jointures très rapides, exploitant un système de jointures multiples en une seule passe optimisée.

    • Tables en mémoire, pour réaliser des tables temporaires.

    • Les fonctions SQL sont implémentées grâce à une bibliothèque de classes optimisées, qui sont aussi rapides que possible! Généralement, il n'y a aucune allocation mémoire une fois que la requête a été initialisée.

    • Le code de MySQL est vérifié avec Purify (un utilitaire de détection des fuites mémoires commercial) ainsi qu'avec Valgrind, un outil GPL (http://developer.kde.org/~sewardj/).

  • Types de colonnes

    • Nombreux types de colonnes : entiers signés ou non, de 1, 2, 3, 4, et 8 octets, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET et ENUM. See Chapitre 11, Types de colonnes.

    • Enregistrements de taille fixe ou variable.

    • Toutes les colonnes ont des valeurs par défaut. Vous pouvez utiliser la commande INSERT pour insérer un sous ensemble de colonnes : les colonnes qui ne sont pas explicitement cités prennent alors leur valeur par défaut.

  • Commandes et fonctions

    • Support complet des opérateurs et fonctions dans la commande SELECT et la clause WHERE. Par exemple :

      mysql> SELECT CONCAT(first_name, " ", last_name)
          -> FROM tbl_name
          -> WHERE income/dependents > 10000 AND age > 30;
      
    • Support complet des clauses SQL GROUP BY et ORDER BY. Support des fonctions de groupages (COUNT(), COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX() et MIN()).

    • Support des clauses LEFT OUTER JOIN et RIGHT OUTER JOIN avec les syntaxes ANSI SQL et ODBC.

    • Les alias de tables et colonnes sont compatibles avec le standard SQL92.

    • DELETE, INSERT, REPLACE et UPDATE retourne le nombre de lignes affectées. Il est possible d'obtenir le nombre de lignes trouvées en modifiant une option lors de la connexion au serveur.

    • La commande spécifique à MySQL SHOW est utilisée pour obtenir des informations sur les bases, tables et index. La commande EXPLAIN sert à optimiser les requêtes.

    • Les noms de fonctions ne sont jamais en conflit avec les noms de tables ou colonnes. Par exemple, ABS est un nom de colonne valide. La seule restriction est que, lors d'un appel de fonction, aucun espace n'est toléré entre le nom de la fonction et la parenthèse ouvrante ‘(’ suivante. See Section 9.6, « Cas des mots réservés MySQL ».

    • Vous pouvez utiliser simultanément des tables de différentes bases (depuis la version 3.22).

  • Sécurité

    • Un système de droits et de mots de passe très souple et sécuritaire, qui vérifie aussi les hôtes se connectant. Les mots de passe sont bien protégés, car tout les échanges de mot de passe sont chiffrés, même lors des connexions.

  • Charges supportées et limites

    • Gère les très grandes bases de données. Nous utilisons le serveur MySQL avec des bases qui contiennent 50 millions de lignes et nous connaissons des utilisateurs qui utilisent le serveur MySQL avec plus de 60 000 tables et 5 000 000 000 (milliards) de lignes.

    • Jusqu'à 32 index sont permis par table. Chaque index est constitué de 1 à 16 colonnes ou parties de colonnes. La taille maximale d'un index est de 500 octets (ce qui peut être configuré à la compilation du serveur MySQL. Un index peut utiliser un préfixe issu d'un champs CHAR ou VARCHAR.

  • Connexions

    • Les clients peuvent se connecter au serveur MySQL en utilisant les sockets TCP/IP, les sockets Unix ou les pipes nommés sous NT.

    • Support de ODBC (Open-DataBase-Connectivity) pour Windows 32 bits (avec les sources). Toutes les fonctions ODBC 2.5 et de nombreuses autres. Par exemple, vous pouvez utiliser MS Access pour vous connecter au serveur MySQL. See Section 25.1.1.1, « Qu'est-ce que ODBC? ».

    • L'interface Connector/JDBC fournit le support pour les clients Java qui utilisent JDBC. Ces clients peuvent être utilisés sur Windows et Unix. Les sources de Connector/JDBC sont libres. See Chapitre 25, Pilotes MySQL.

  • Traductions

    • Le serveur fournit des messages d'erreurs au client dans de nombreuses langues, y compris le fran¸ais. See Section 5.8.2, « Langue des messages d'erreurs ».

    • Support complet de plusieurs jeux de caractères, comprenant ISO-8859-1 (Latin1), german, big5, ujis, etc. Par exemple, les caractères nordiques ‘Â’, ‘ä’ et ‘ö’ sont autorisés dans les noms de tables et colonnes.

    • Toutes les données sont sauvées dans le jeu de caractères choisi. Les comparaisons normales de chaînes sont insensibles à la casse.

    • Le tri est fait en fonction du jeu de caractères choisi (par défaut, le jeu suédois). Il est possible de le changer lorsque le serveur MySQL est démarré. Pour voir un exemple très avancé de tri, voyez le code de tri pour le Tchèque. Le serveur MySQL supporte de nombreux jeux de caractères qui peuvent être spécifié à la compilation et durant l'exécution.

  • Clients et utilitaires

    • Inclut myisamchk, un utilitaire rapide pour vérifier les tables, les optimiser et les réparer. Toutes les fonctionnalités de myisamchk sont aussi disponibles via l'interface SQL. See Chapitre 5, Administration du serveur.

    • Tous les programmes MySQL peuvent être appelés avec l'option --help ou -? pour obtenir de l'aide en ligne.

1.2.3 Jusqu'à quel point MySQL est il stable ?

Cette section répond aux questions ``Jusqu'à quel point MySQL est-il stable ?'' et ``Puis-je faire confiance à MySQL pour mon projet ?'' Nous allons tenter d'apporter des réponses claires à ces questions importantes qui concernent tous les utilisateurs potentiels. Les informations de cette section sont fournies par les listes de diffusions, qui sont très actives et promptes à identifier les problèmes et les rapporter.

Le code original date du début des années 80 et fournit une base de code stable, tout en assurant une compatibilité ascendante avec le format ISAM. A TcX, le prédécesseur de MySQL AB, le code de MySQL a fonctionné sur des projets depuis la mi 1996, sans aucun problème. Lorsque le Serveur MySQL a été livré à un public plus large, nous avons réalisé qu'il contenait du code ``jamais testé'' qui a été rapidement identifié par les utilisateurs, qui effectuait des requêtes différentes des nôtres. Chaque nouvelle version avait moins de problèmes de portabilité, même si chaque nouvelle version avait de nombreuses nouvelles fonctionnalités.

Chaque version du Serveur MySQL était parfaitement fonctionnelle. Les seuls problèmes étaient rencontrés par les utilisateurs de code de ces ``zone d'ombres''. Naturellement, les nouveaux utilisateurs ne connaissent pas ces zones : cette section tente de les présenter, dans la mesure de nos connaissances. Les descriptions correspondent surtout aux versions 3.23 du Serveur MySQL. Tous les bogues connus et rapportés ont été corrigés dans la dernière version, à l'exception de ceux qui sont listés dans la section Bugs, qui sont des problèmes de conception. See Section 1.5.7, « Erreurs connues, et limitations de MySQL ».

La conception du serveur MySQL est faite en plusieurs couches, avec des modules indépendants. Certains des modules les plus récents sont listés ici, avec leur niveau de test :

  • Réplication -- Gamma

    De grands serveurs en grappe utilisant la réplication sont en production, avec de bons résultats. L'amélioration de la réplication continue avec MySQL 4.x.

  • Tables InnoDB -- Stable (en 3.23 depuis 3.23.49)

    Le gestionnaire transactionnel de tables InnoDB a été déclaré stable en MySQL version 3.23, à partir de la version 3.23.49. InnoDB est utilisé dans de grands systèmes complexes, avec forte charge.

  • Tables BDB -- Gamma

    Le code de Berkeley DB est très stable, mais nous sommes encore en train d'améliorer l'interface du gestionnaire transactionnel de table BDB du serveur MySQL. Cela demande encore du temps pour qu'il soit aussi bien testé que les autres types de tables.

  • FULLTEXT -- Beta

    La recherche en texte plein fonctionne mais n'est pas encore largement adoptée. Des améliorations importantes sont prévues pour MySQL 4.0.

  • Connector/ODBC 3.51 (Stable)

    Connector/ODBC 3.51 utilise le SDK ODBC SDK 3.51 et est en production. Certains problèmes qui ont surgi sont liée aux applications, et indépendant du pilote ODBC ou le serveur sous-jacent.

  • Tables à restauration automatique MyISAM -- Gamma

    Ce statut ne concerne que le nouveau code du gestionnaire de tables MyISAM qui vérifie si la table a été correctement fermée lors de l'ouverture, et qui exécute automatiquement la vérification et réparation éventuelles de la table.

MySQL AB fournit un support de première qualité pour les clients payant, mais les listes de diffusions de MySQL sont généralement rapides à donner des réponses aux questions les plus communes. Les bogues sont généralement corrigés aussitôt avec un patch. Pour les bogues sérieux, il y a presque toujours une nouvelle version.

1.2.4 Quelles tailles peuvent atteindre les tables MySQL

MySQL version 3.22 a une limite de 4Go par table. Avec le nouveau format de table MyISAM, disponible avec MySQL version 3.23, la taille maximale des tables a été poussée à 8 millions de teraoctets (2 ^ 63 octets).

Notez, toutefois, que les systèmes d'exploitation ont leur propres limites. Voici quelques exemples :

Système d'exploitationLimite
Linux-Intel 32 bit2Go, 4Go ou plus, suivant la version de Linux
Linux-Alpha8To (?)
Solaris 2.5.12Go (4Go possibles avec un patch)
Solaris 2.64Go (peut être modifié avec une option)
Solaris 2.7 Intel4Go
Solaris 2.7 UltraSPARC512Go
NetWare avec/NSS8TB

En Linux 2.2, vous pouvez avoir des tables plus grandes que 2Go en utilisant le patch LFS pour les systèmes de fichiers ext2. En Linux 2.4, le patche existe aussi pour ReiserFS. La plupart des distribution Linux courantes sont basées sur un noyau 2.4, et supporte déjà tous les patches pour les grands fichiers (LFS). Cependant, la taille maximale de fichier dépend de nombreux facteurs, notamment le système de fichiers utilisé pour stocker les pages MySQL.

Pour une introduction détaillée à LFS sur Linux, voyez la page d' Andreas Jaeger Large File Support in Linux à http://www.suse.de/~aj/linux_lfs.html.

Par défaut, les tables MySQL peuvent atteindre une taille de 4Go. Vous pouvez vérifier la taille des tables avec la commande SHOW TABLE STATUS ou la commande en ligne myisamchk -dv nom_de_table. See Section 13.5.3, « Syntaxe de SHOW ».

Si vous avez besoin de tables plus grandes que 4Go (et que votre système d'exploitation le supporte, modifiez les paramètres AVG_ROW_LENGTH et MAX_ROWS lorsque vous créez votre table. See Section 13.2.5, « Syntaxe de CREATE TABLE ». Vous pouvez aussi modifier ces valeurs avec la commande ALTER TABLE. See Section 13.2.2, « Syntaxe de ALTER TABLE ».

D'autres méthodes pour contourner les limitations des systèmes de fichiers avec les tables MyISAM :

1.2.5 Compatibilité an 2000

Le serveur MySQL lui même n'a aucun problème de compatibilité avec l'an 2000 (Y2K) :

  • Le serveur MySQL utilise les fonctions de date Unix, et n'a aucun problème avec les dates jusqu'en 2069; toutes les années écrites en deux chiffres sont supposées faire partie de l'intervalle allant de 1970 à 2069, ce qui signifie que si vous stockez la date 01 dans une colonne de type year, le serveur MySQL la traitera comme 2001.

  • Toutes les fonctions de dates de MySQL sont stockées dans un fichier sql/time.cc, et sont codées très soigneusement pour être compatibles avec l'an 2000.

  • En MySQL version 3.22 et plus récent, le type de colonne YEAR peut stocker les valeurs 0 et de 1901 à 2155 sur un seul octet, tout en affichant 2 ou 4 chiffres.

Vous pouvez rencontrer des problèmes avec les applications qui utilisent le serveur MySQL sans être compatible avec l'an 2000. Par exemple, les vieilles applications utilisent des valeurs d'années sur deux chiffres (ce qui est ambigu), plutôt qu'avec 4 chiffres. Ce problème peut être complété par des applications qui utilisent des valeurs telles que 00 ou 99 comme indicateur de données ``manquante''.

Malheureusement, ces problèmes peuvent se révéler difficiles à corriger car différentes applications peuvent être écrites par différents programmeurs, et chacun utilise un jeu différent de conventions et de fonctions de gestion des dates.

Voici une illustration simple qui montre que le serveur MySQL n'a aucun problème avec les dates jusqu'en 2030 :

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE y2k (date DATE,
    ->                   date_time DATETIME,
    ->                   time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO y2k VALUES
    -> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
    -> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
    -> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
    -> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
    -> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
    -> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
    -> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
    -> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
    -> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
    -> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
    -> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
    -> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date       | date_time           | time_stamp     |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

Cet exemple montre que les types DATE et DATETIME ne poseront aucun problème avec les dates futures (ils gèrent les dates jusqu'en 9999).

Le type TIMESTAMP, qui est utilisé pour stocker la date courante, est valide jusqu'en 2030-01-01. TIMESTAMP va de 1970 en 2030 sur les machines 32 bits (valeur signée). Sur les machines 64 bits, il gère les dates jusqu'en 2106 (valeur non signée).

Même si le serveur MySQL est compatible an 2000, il est de votre responsabilité de fournir des données non ambiguës. Voyez Section 11.3.4, « An 2000 et les types date » pour les règles du serveur MySQL pour traiter les dates ambiguës (les données contenant des années exprimées sur deux chiffres).

1.3 Plan de développement de MySQL

Cette section donne un aper¸u du plan de développement de MySQL, incluant les futures fonctionnalités prévues pour MySQL 4.0, 4.1, 5.0 et 5.1. Les sections suivantes donnent plus de détails sur chaque version.

La série de production est MySQL 4.0, qui a été déclarée stable pour un environnement de production depuis la version 4.0.12, publiée en Mars 2003. Cela signifie que les développements futurs de la série des 4.0 est limitée aux corrections de bugs. Pour les anciennes version 3.23, seuls les bogues critiques seront corrigés.

L'effort de développement MySQL a lieu actuellement dans les versions MySQL 4.1 et 5.0. Cela signifie que les nouvelles fonctionnalités sont ajoutées aux versions 4.1 et 5.0. Les versions 4.1 et 5.0 sont disponibles en version alpha.

Avant de mettre à jour une version vers une autre, lisez les notes de la section Section 2.6, « Changer de version de MySQL ».

Les plans de certains fonctionnalités sont résumés dans cette table.

Fonctionnalitéversion MySQL
Unions4.0
Sous-requêtes4.1
R-trees4.1 (pour les tables MyISAM)
Procédures stockées5.0
Vues5.0 ou 5.1
Curseurs5.0
Clés étrangères5.1 (déjà implémentées en 3.23 par InnoDB)
Triggers5.1
Jointures externes5.1
Contraintes5.1

1.3.1 MySQL 4.0 en bref

Promise depuis longtemps par MySQL AB et attendue avec impatience par nos utilisateur, le serveur MySQL 4.0 est disponible en version de production.

MySQL 4.0 est disponible au téléchargement depuis http://www.mysql.com/ et nos miroirs. MySQL 4.0 a été testé par un grand nombre d'utilisateurs et il est en production sur de très grands sites.

Les fonctionnalités principales de MySQL serveur 4.0 sont destinées à nos utilisateurs professionnels et communautaire : elles améliorent le capacités de MySQL pour gérer les missions critiques et les systèmes fortement chargés. D'autres fonctionnalités sont destinées aux utilisateurs de solutions intégrées.

1.3.1.1 Fonctionnalités disponibles en MySQL 4.0

  • Amélioration des performances

    • MySQL 4.0 dispose d'un cache de requêtes qui peut vous accélérer grandement vos applications qui utilisent souvent les mêmes requêtes. See Section 5.11, « Cache de requêtes MySQL ».

    • La version 4.0 accélère la vitesse du serveur MySQL dans de nombreux domaines, notamment les INSERT de masse, la recherche sur les index compressés, la création d'index FULLTEXT ainsi que les comptes COUNT(DISTINCT).

  • Serveur MySQL embarqué

  • Le moteur InnoDB en standard

    • Le moteur de tables InnoDB est désormais livré en standard avec le serveur MySQL, apportant le support complet des transactions ACID, les clés étrangères avec modifications et effacement en cascade, ainsi que le verrouillage de ligne. See Chapitre 15, Le moteur de tables InnoDB.

  • Nouvelles fonctionnalités

    • Les nouvelles possibilités de recherche en FULLTEXT de MySQL Serveur 4.0 permettent l'utilisation d'index FULLTEXT sur de grandes quantités de texte, avec des logiques binaires ou en langage naturel. Les utilisateurs peuvent paramétrer la taille minimum des mots, et définir leur propre liste de mots interdits, dans n'importe quel langue. Cela ouvre la possibilité de nombreuses applications avec MySQL Serveur. See Section 12.6, « Recherche en texte intégral (Full-text) dans MySQL ».

  • Respect des standards, portabilité et migration

    • Simplification de la migration depuis d'autres bases de données vers MySQL Serveur, et notamment TRUNCATE TABLE (comme sous Oracle) et IDENTITY comme synonyme pour les clés automatiquement incrémentées (comme sous Sybase).

    • De nombreux utilisateurs seront heureux de savoir que le serveur MySQL supporte aussi les requêtes UNION, une fonctionnalité SQL attendue avec impatience.

    • MySQL peut s'exécuter nativement sur les plates-formes NetWare 6.0. See Section 2.2.14, « Installer MySQL sur NetWare ».

  • Internationalisation

    • Nos utilisateurs allemands, autrichiens et suisses remarqueront que nous avons un nouveau jeu de caractères, latin1_de, qui corrige les problèmes de tri des valeurs allemandes, en pla¸ant les umlauts allemands dans le même ordre que dans l'annuaire d'Allemagne.

  • Amélioration de l'ergonomie

    Durant la mise en place de fonctionnalités pour de nouveaux utilisateurs, nous n'avons pas oublié notre communauté de loyaux utilisateurs.

    • Une fonctionnalité pratique pour les administrateurs de base de données est que la plupart des paramètres de démarrage de mysqld peuvent être modifiées sans redémarrer le serveur. See Section 13.5.2.8, « Syntaxe de SET ».

    • Les commandes DELETE et UPDATE peuvent désormais fonctionner sur plusieurs tables.

    • En ajoutant le support des liens symboliques à MyISAM au niveau des tables (et non plus au niveau des bases, comme auparavant), et en autorisant les liens symboliques sur Windows, nous espérons que nous avons pris au sérieux vos demandes d'amélioration.

    • Des fonctions comme SQL_CALC_FOUND_ROWS et FOUND_ROWS() rendent possible le comptages de lignes sans utiliser la clause LIMIT.

La section sur les nouveautés du manuel rassemble toutes les nouveautés. See Section C.3, « Changements de la version 4.0.x (Production) ».

1.3.1.2 MySQL Server intégré (embedded)

libmysqld rend le serveur MySQL disponible pour toute une gamme d'applications très vaste. En utilisant la bibliothèque du serveur MySQL intégré, vous pouvez utiliser MySQL dans différentes applications et appareillages, où l'utilisateur final n'aura même pas idée de sa présence. Le serveur MySQL intégré est idéal pour équiper les bornes internet, les kiosques publics, les paquets matériel/ logiciels clé en main, les serveurs MySQL haute performances, et les bases de données autonomes sur CDrom.

De nombreux utilisateurs de libmysqld profiteront de la double licence. Pour ceux qui ne souhaitent pas être liés par la licence GPL, la bibliothèque est aussi disponible avec une licence commerciale. La bibliothèque MySQL intégrée utilise la même interface que la bibliothèque cliente classique, ce qui la rend pratique à utiliser. See Section 24.2.16, « libmysqld, la bibliothèque du serveur embarqué MySQL ».

1.3.2 MySQL 4.1 en bref

MySQL 4.0 a posé les fondations pour de nouvelles fonctionnalités telles que les sous-requêtes imbriquées et l'Unicode qui sont d'ores et déjà implémentées en version 4.1, ainsi que les procédures stockées SQL-99, qui seront disponibles pour la version 5.0. Ils représentent les fonctionnalités les plus demandées par de nombreux clients.

Avec ces améliorations, les critiques du serveur de base de données MySQL devront être plus imaginatifs que jamais pour identifier des manques dans le serveur MySQL. Déjà connu depuis longtemps pour sa stabilité, sa rapidité et sa facilité d'emploi, le serveur MySQL va désormais satisfaire la liste de tous les voeux des clients les plus exigeants.

1.3.2.1 Fonctionnalités disponibles en MySQL 4.1

Les fonctionnalités ci-dessous sont implémentées en MySQL 4.1. Quelques autres fonctionnalités sont prévues pour MySQL 4.1, mais très peu. Voyez See Section B.8.1, « Nouvelles fonctionnalités prévues pour la version 5.0 ».

Les plus récentes fonctionnalités en cours de réalisation, comme par exemple les procédures stockées, seront disponibles en MySQL 5.0. See Section B.8.1, « Nouvelles fonctionnalités prévues pour la version 5.0 ».

  • Support des sous-requêtes et tables dérivées

  • Accélération

  • Nouvelle fonctionnalité

    • CREATE TABLE table_name2 LIKE table_name1 vous permet de créer, avec une seule commande, une nouvelle table, avec une structure identique à celle d'une autre table existante.

    • Support pour les types géométriques OpenGIS (données géométriques). See Chapitre 18, Données spatiales avec MySQL.

    • La réplication peut être faite sur connexions SSL.

  • Compatibilité avec les standards, portabilité et migration

    • Le nouveau protocole client-serveur apporte la possibilité de faire passer plusieurs alertes au client, plutôt qu'une seule. Cela améliore grandement la gestion des erreurs lors des manipulations de masse.

    • SHOW WARNINGS affiche les erreurs de la dernière commande. See Section 13.5.3.19, « SHOW WARNINGS | ERRORS ».

  • Internationalisation

    • Pour supporter notre base d'utilisateurs en pleine croissance, et leur configurations locales, MySQL exploite désormais l'Unicode (UTF8).

    • Les jeux de caractères peuvent désormais être définis par colonnes, tables et bases. Cela permet d'améliorer la souplesse dans la conception des applications, en particuliers pour les sites multi-langues.

    • Pour la documentation sur l'amélioration du support des jeux de caractères, voyez Chapitre 10, Jeux de caractères et Unicode.

  • Améliorations d'ergonomie

    • En réponse à la demande populaire, nous avons ajouté une commande HELP command coté serveur, qui peut être utilisée en ligne de commande du client mysql et d'autres clients, pour obtenir de l'aide sur les commandes SQL. Avec ces informations sur le serveur, elles seront parfaitement adaptées à la version et configuration du serveur.

    • Avec le nouveau protocole client/serveur, les requêtes multiples sont désormais activées. Cela vous permet d'émettre plusieurs requêtes en une seule commande, puis de lire tous les résultats en une seule fois. See Section 24.2.9, « Gestion des commandes multiples avec l'interface C ».

    • Le nouveau protocole client/serveur supporte aussi les jeux de résultats multiples. Cela peut arriver après une commande multiple, par exemple. Voir le point précédent.

    • Nous avons implémenté une syntaxe pratique INSERT ... ON DUPLICATE KEY UPDATE .... Elle vous permet de modifier une ligne avec UPDATE, si l'insertion INSERT avait généré un double dans la colonne PRIMARY ou UNIQUE. See Section 13.1.4, « Syntaxe de INSERT ».

    • Nous avons ajouté une fonction d'agrégation, GROUP_CONCAT(), qui permet de concaténer des colonnes dans une seule chaîne de résultat. See Section 12.9, « Fonctions et options à utiliser dans les clauses GROUP BY ».

La section sur les nouveautés du manuel rassemble toutes les nouveautés. See Section C.2, « Changements de la version 4.1.x (Alpha) ».

1.3.3 MySQL 5.0, les prochains développements

Les nouveaux développements de MySQL sont désormais concentrés sur la version 5.0. Les procédures stockées et d'autres fonctionnalités seront en vedette. See Section B.8.1, « Nouvelles fonctionnalités prévues pour la version 5.0 ».

Pour ceux qui veulent jeter un oeil aux tout derniers développements de MySQL, nous avons rendu notre serveur BitKeeper disponible au public pour MySQL version 5.0. See Section 2.4.3, « Installer à partir de l'arbre source de développement ». Depuis décembre 2003, des paquets binaires de MySQL version 5.0 sont aussi disponibles.

1.4 Sources d'informations MySQL

1.4.1 Listes de diffusion MySQL

Cette section vous présente les listes de diffusions MySQL, et donne des conseils quand à leur utilisation. En vous inscrivant à une des listes de diffusion, vous recevrez les messages que les autres auront envoyé, et vous pourrez envoyer vos propres questions et réponses.

1.4.1.1 Les listes de diffusion de MySQL

Pour vous inscrire ou vous désinscrire à la liste de diffusion principale de MySQL, visitez le site http://lists.mysql.com/. N'envoyez pas de messages pour vous inscrire ou vous désinscrire sur la liste, car ces messages seront transmis automatiquement à des milliers d'utilisateurs.

Votre site local peut avoir beaucoup d'inscrits à une liste de diffusion. Si c'est le cas, vous pouvez avoir une liste de diffusion locale, de fa¸on à ce que les messages envoyés par lists.mysql.com à votre site local soit propagés par votre serveur local. Dans ce cas, contactez votre administrateur local pour être ajouté ou retiré de la liste.

Si vous voulez que le trafic de cette liste soit envoyé à une autre boîte aux lettres de votre client mail, installez un filtre basé sur les entêtes du message. Vous pouvez utiliser notamment les entêtes List-ID: et Delivered-To: pour identifier les messages de la liste.

Les listes de diffusion MySQL suivantes existent :

  • announce

    Ceci est la liste de diffusion d'annonces des versions de MySQL et des programmes compagnons. C'est une liste à faible volume, et tout utilisateur doit y être inscrit.

  • mysql

    La liste de diffusion principale pour les discussions générales sur MySQL. Notez que certains sujets sont à diriger sur les listes spécialisées. Si vous postez sur la mauvaise liste, vous pourriez ne pas avoir avoir de réponse.

  • mysql-digest

    La liste mysql en format journalier. Cela signifie que vous recevrez tous les messages de la journée en un seul gros email.

  • bugs

    Sur cette liste, vous ne devriez envoyez que des bogues complets, reproductibles ainsi que le rapport qui va avec, en utilisant le script mysqlbug (si vous utilisez Windows, il faut aussi inclure la description du système d'exploitation et la version de MySQL). See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».

  • bugs-digest

    La liste bugs en format journalier.

  • internals

    Une liste pour ceux qui travaillent sur le code MySQL. Sur cette liste, vous pouvez discuter du développement de MySQL et envoyer des correctifs.

  • internals-digest

    La liste internals en format journalier.

  • mysqldoc

    La liste des personnes qui travaillent sur la documentation MySQL : des employés de MySQL AB, des traducteurs et d'autres membres de la communauté.

  • mysqldoc-digest

    La liste mysqldoc en format journalier.

  • benchmarks

    Cette liste est pour tous ceux qui sont intéressé par les performances. Les discussions se concentrent sur les performances (mais pas seulement avec MySQL), mais abordent aussi des problèmes de noyau, le système de fichiers, les disques, etc.

  • benchmarks-digest

    La liste benchmarks en format journalier.

  • packagers

    Cette liste se concentre sur les paquets et les distributions MySQL. C'est l'un des forums utilisé par les responsables pour échanger des idées sur les paquets MySQL, pour s'assurer que MySQL est le même sur toutes les plates-formes.

  • packagers-digest

    La liste packagers en format journalier.

  • java

    Une liste pour ceux qui utilisent MySQL et java. Elle concerne majoritairement les pilotes JDBC.

  • java-digest

    La liste java en format journalier.

  • win32

    Une liste pour ceux qui utilisent MySQL sur les systèmes d'exploitation de Microsoft, tels que Windows 9x/Me/NT/2000/XP.

  • win32-digest

    La liste win32 en format journalier.

  • myodbc

    Une liste pour tout ce qui concerne la connexion à MySQL avec le pilote ODBC.

  • myodbc-digest

    La liste myodbc en format journalier.

  • mysqlcc

    Une liste pour tout ce qui concerne le client graphique MySQL Control Center.

  • mysqlcc-digest

    La liste mysqlcc en format journalier.

  • plusplus

    Une liste pour tout ce qui concerne la programmation avec les API C++ de MySQL.

  • plusplus-digest

    La liste plusplus en format journalier.

  • msql-mysql-modules

    Une liste pour tout ce qui concerne Perl et le support du module msql / mysql.

  • msql-mysql-modules-digest

    La liste msql-mysql-modules en format journalier.

Vous pouvez vous inscrire ou vous désinscrire de toutes les listes en même temps de la même fa¸on que nous l'avons décrit au début. Dans votre message d'inscription, utilisez simplement le nom de liste approprié. Par exemple, pour vous inscrire à la liste myodbc.

Si vous ne pouvez pas obtenir d'informations sur la liste de diffusion, une de vos options est de prendre un contrat de support auprès de MySQL AB, qui vous donnera un contact direct avec les développeurs MySQL.

Le tableau suivant présente diverses autres listes de diffusions consacrée à MySQL, dans d'autres langues que l'anglais. Notez que ces ressources ne sont pas gérées par MySQL AB, ce qui fait que nous ne pouvons pas garantir leur qualité.

1.4.1.2 Poser des questions ou rapporter un bogue

Avant de soumettre un rapport de bogue ou une question, commencez par ces étapes simples :

  • Etudiez le manuel MySQL et faites y une recherche à : http://www.mysql.com/doc/ Nous nous effor¸ons de mettre à jour le manuel fréquemment, en y ajoutant les solutions aux nouveaux problèmes. L'historique de modification (http://www.mysql.com/doc/en/News.html) est particulièrement pratique car il est possible qu'une nouvelle version de MySQL propose déjà la solution à votre problème.

  • Cherchez dans la base de données des bogues sur http://bugs.mysql.com/ pour voir si le bogue a déjà été rapporté ou résolu.

  • Recherchez dans les archives des listes de diffusion de MySQL : http://lists.mysql.com/

  • Vous pouvez aussi utiliser l'URL http://www.mysql.com/search/ pour rechercher dans toutes les pages web (y compris le manuel) sur le site web de MySQL.

Si vous n'arrivez pas à trouver une réponse à votre question dans le manuel ou dans les archives, vérifiez auprès de votre expert MySQL local. Si vous ne trouvez toujours pas la réponse, vous pouvez lire la section suivante.

1.4.1.3 Comment rapporter un bogue ou un problème

Notre base de données de bogues est publique, et peut être lue par tous sur le site http://bugs.mysql.com/. Si vous vous identifiez sur le système vous serez aussi capable d'envoyer des rapports.

Ecrire un bon rapport de bogue requiert de la patience, et le faire dès le début épargnera votre temps et le notre. Un bon rapport de bogue qui contient un cas de test complet améliorera vos chances de voir le bogue corrigé à la prochaine version. Cette section vous aidera à écrire correctement un rapport de bogue, de manière à ce que vous ne gaspillez pas votre temps à faire des textes qui ne nous aideront que peu ou pas.

Nous vous recommandons d'utiliser le script mysqlbug pour générer un rapport de bogue (ou rapporter un problème), dans la mesure du possible. mysqlbug est situé dans le dossier scripts de la distribution, ou, pour les distributions binaire, dans le dossier bin du dossier d'installation de MySQL. Si vous êtes dans l'incapacité d'utiliser mysqlbug, vous devez tout de même inclure toutes les informations nécessaires listées dans cette section.

Le script mysqlbug vous aide à générer un rapport en déterminant automatiquement les informations suivantes, mais si quelque chose d'important lui échappe, ajoutez le dans votre message! Lisez cette section avec attention, et assurez vous que toutes les informations décrites ici sont présentes dans votre message.

De préférence, vous devriez tester le problème avec la dernière version de production ou de développement de MySQL. Il doit être facile de reproduire le test avec simplement la commande ‘mysql test < script’, appliquée au cas de test, ou en exécutant le script Shell ou Perl inclus dans le rapport.

Tous les bogues postés sur le site de rapports de bogues http://bugs.mysql.com/ seront corrigés ou documentés dans la prochaine version de MySQL. Si seuls, de petits changements sont nécessaires, nous publierons aussi un patch.

Si vous avez découvert un problème de sécurité critiques avec MySQL, il faut envoyer un email à .

Si vous avez un rapport de bogue reproductible, envoyez un rapport sur le site http://bugs.mysql.com/. Notez que même dans ce cas, il est bon d'utiliser le script mysqlbug pour rassembler des informations sur votre système. Tous les bogues que nous pourrons reproduire auront de bonnes chances d'être corrigés lors de la prochaine version de MySQL.

Pour signaler d'autres problèmes, utilisez une des listes de diffusion MySQL.

Sachez qu'il est toujours possible de répondre à un message qui contient trop d'informations, alors qu'il est impossible de répondre à un message qui contient trop peu d'informations. Souvent, il est facile d'omettre des faits parce que vous pensez connaître la cause du problème et supposez que ces détails ne sont pas importants. Un bon principe à suivre est : si vous avez un doute à propos de quelque chose, faites nous en part. Il est bien plus rapide et bien moins frustrant d'écrire quelques lignes de plus dans un rapport plutôt que d'être obligé de demander une nouvelle fois et d'attendre une réponse parce que vous avez oublié une partie des informations la première fois.

L'erreur la plus commune est de ne pas indiquer le numéro de la version de MySQL qui est utilisé, ou de ne pas indiquer le système d'exploitation que vous utilisez (y compris le numéro de version de ce système d'exploitation). Ce sont des informations de première importance, et dans 99% des cas, le rapport de bogue est inutilisable sans ces informations. Souvent, nous recevons des questions telles que ``Pourquoi est ce que cela ne fonctionne pas pour moi ?''. Puis nous nous apercevons que la fonctionnalités en question n'est même pas programmée dans la version de MySQL utilisée, ou que le bogue décrit est déjà corrigé dans une nouvelle version de MySQL. Parfois aussi, les erreurs sont dépendantes des plates-formes. Dans ce cas, il est presque impossible de les corriger sans savoir quel système d'exploitation et quelle version exacte est utilisée.

Pensez aussi à fournir des informations concernant votre compilateur, si c'est pertinent. Souvent, les développeurs trouvent des bogues dans les compilateurs, et pensent que c'est liés à MySQL. La plupart des compilateurs sont en constant développement, et s'améliorent de version en version. Pour déterminer si votre problème dépend de votre compilateur, nous avons besoin de savoir quel compilateur est utilisé. Notez que les problèmes de compilations sont des bogues, et doivent être traités avec un rapport de bogues.

Il est particulièrement utile de fournir une bonne description du bogue dans le rapport de bogue. Cela peut être un exemple de ce que vous avez fait qui a conduit au problème, ou une description précise. Les meilleurs rapports sont ceux qui incluent un exemple complet permettant de reproduire le bogue. See Section D.1.6, « Faire une batterie de tests lorsque vous faites face à un problème de table corrompue ».

Si un programme produit un message d'erreur, il est très important d'inclure ce message dans votre rapport. Il est préférable que le message soit le message exact, car il est alors possible de le retrouver en utilisant les archives : même la casse doit être respectée. N'essayez jamais de vous rappeler d'un message d'erreur, mais faites plutôt un copier/coller du message complet dans votre rapport.

Si vous avez un problème avec MyODBC, essayez de générer un fichier de trace MyODBC. See Section 25.1.1.9, « Rapporter des problèmes avec MYODBC ».

Pensez aussi que de nombreux personnes qui liront votre rapport utilisent un formatage de 80 colonnes. Lorsque vous générez votre rapport et vos exemples avec l'outil de ligne de commande, utilisez une largeur de 80 colonnes. Utilisez l'option --vertical (ou la fin de commande \G) pour les affichages qui excèdent une telle largeur (par exemple, avec la commande EXPLAIN SELECT; voyez l'exemple un peu plus tard dans cette section.

Voici un pense-bête des informations à fournir dans votre rapport :

  • Le numéro de version de la distribution de MySQL que vous utilisez (par exemple MySQL Version 3.22.22). Vous pouvez connaître cette version en exécutant la commande mysqladmin version. mysqladmin est situé dans le dossier bin de votre distribution MySQL.

  • Le fabricant et le modèle de votre serveur.

  • Le système d'exploitation et la version que vous utilisez. Pour la plupart des systèmes d'exploitation, vous pouvez obtenir cette information en utilisant la commande Unix uname -a.

  • Parfois, la quantité de mémoire (physique et virtuelle) est important. Si vous hésitez, ajoutez la.

  • Si vous utilisez une version de MySQL sous forme de source, le nom et le numéro de version du compilateur sont nécessaires. Si vous utilisez une version exécutable, le nom de la distribution est important.

  • Si le problème intervient lors de la compilation, incluez le message d'erreur exact et les quelques lignes de contexte autour du code en question dans le fichier où il est situé.

  • Si mysqld s'est arrêté, il est recommandé d'inclure la requête qui a mené à cet arrêt de mysqld. Vous pouvez généralement la trouver en exécutant mysqld en ayant activé les logs. See Section D.1.5, « Utilisation des fichiers de log pour trouver d'où viennent les erreurs de mysqld ».

  • Si une table ou une base sont liés au problème ajoutez le résultat de la commande mysqldump --no-data db_name tbl_name1 tbl_name2 .... C'est très simple à faire, et c'est un moyen efficace d'obtenir un descriptif de table, qui nous permettra de recréer une situation comparable à la votre.

  • Pour les problèmes liés à la vitesse, ou des problèmes liés à la commande SELECT, pensez à inclure le résultat de la commande EXPLAIN SELECT ..., et au moins le nombre de ligne que la commande SELECT doit produire. Vous devriez aussi inclure le résultat de la commande SHOW CREATE TABLE table_name pour chaque table impliquée. Plus vous nous fournirez d'informations, plus nous aurons de chance de vous aider efficacement. Par exemple, voici un excellent rapport de bogue (posté avec le script mysqlbug, et effectivement rédigé en anglais) :

    Exemple réalisé avec mysql en ligne de commande (notez l'utilisation de la fin de commande \G, pour les résultats qui pourraient dépasser les 80 colonnes de large) :

    mysql> SHOW VARIABLES;
    mysql> SHOW COLUMNS FROM ...\G
           <output from SHOW COLUMNS>
    mysql> EXPLAIN SELECT ...\G
           <output from EXPLAIN>
    mysql> FLUSH STATUS;
    mysql> SELECT ...;
           <A short version of the output from SELECT,
           including the time taken to run the query>
    mysql> SHOW STATUS;
           <output from SHOW STATUS>
    
  • Si un bogue ou un problème survient lors de l'exécution de mysqld, essayez de fournir un script qui reproduit l'anomalie. Ce script doit inclure tous les fichiers sources nécessaires. Plus votre script reproduira fidèlement votre situation, mieux ce sera. Si vous pouvez réaliser un cas de test postez-le sur le site http://bugs.mysql.com/ pour un traitement prioritaire!

    Si vous ne pouvez pas fournir de script, fournissez tout au moins le résultat de la commande mysqladmin variables extended-status processlist dans votre mail pour fournir des informations sur les performances de votre système.

  • Si vous ne pouvez pas reproduire votre situation en quelques lignes, ou si une table de test est trop grosse à être envoyée par mail (plus de 10 lignes), exportez vos tables sous forme de fichier avec la commande mysqldump et créez un fichier README qui décrit votre problème.

    Créez une archive compressée de votre fichier en utilisant tar et gzip ou zip, et placez le via ftp sur le site de ftp://support.mysql.com/pub/mysql/secret/. Puis, entrez la description de l'anomalie sur le site http://bugs.mysql.com/.

  • Si vous pensez que le serveur MySQL fournit des résultats étranges pour une requête, incluez non seulement le résultat, mais aussi votre propre explication sur ce que le résultat devrait être, et un diagnostic de la situation.

  • Lorsque vous donnez un exemple du problème, il est mieux d'utiliser des noms de variables et de tables qui existent dans votre situation, plutôt que d'inventer de nouveaux noms. Le problème peut être lié au noms des variables ou tables que vous utilisez! Ces cas sont rares, mais il vaut mieux éviter les ambiguïtés. Après tout, il est plus facile pour vous de fournir un exemple qui utilise votre situation réelle, et c'est bien mieux pour nous aussi. Si vous avez des données que vous ne souhaitez pas divulguer, vous pouvez utiliser le site ftp pour les transférer dans le dossier secret ftp://support.mysql.com/pub/mysql/secret/. Si les données sont vraiment ultra secrètes et que vous ne souhaitez même pas nous les montrer, alors utilisez d'autres noms et données pour votre rapport, mais considérez cela comme un dernier recours.

  • Incluez toutes les options utilisées, si possible. Par exemple, indiquez les options que vous utilisez lors du démarrage de mysqld, et celle que vous utilisez avec les programmes comme mysqld et mysql, et le script configure, qui sont souvent primordiaux et pertinents. Ce n'est jamais une mauvaise idée que de les inclure. Si vous utilisez des modules, comme Perl ou PHP, incluez aussi les versions de ces logiciels.

  • Si votre question porte sur le système de droits, incluez le résultat de l'utilitaire mysqlaccess, celui de mysqladmin reload et tous les messages d'erreurs que vous obtenez lors de la connexion. Lorsque vous testez votre système de droits, il faut commencer par utiliser la commande mysqladmin reload version et de vous connecter avec le programme qui vous pose problème. mysqlaccess est situé dans le dossier bin de votre installation de MySQL.

  • Si vous avez un patch pour un bogue, c'est une excellente chose. Mais ne supposez pas que nous n'avons besoin que du patch, ou même que nous allons l'utiliser, si vous ne fournissez pas les informations nécessaires pour le tester. Nous pourrions trouver des problèmes générés par votre patch, ou bien nous pourrions ne pas le comprendre du tout. Si tel est le cas, nous ne l'utiliserons pas.

    Si nous ne pouvons pas vérifier exactement ce pourquoi est fait le patch, nous ne l'utiliserons pas. Les cas de tests seront utiles ici. Montrez nous que votre patch va générer toutes les situations qui pourraient arriver. Si nous trouvons un cas limite dans lequel votre patche ne fonctionne pas, même si il est rare, il risque d'être inutile.

  • Les diagnostics sur la nature du bogue, la raison de son déclenchement ou les effets de bords sont généralement faux. Même l'équipe MySQL ne peut diagnostiquer sans commencer par utiliser un débogueur pour déterminer la cause véritable.

  • Indiquez dans votre mail que vous avez vérifié le manuel de référence et les archives de courrier, de fa¸on à avoir épuiser les solutions que d'autres avant vous auraient pu trouver.

  • Si vous obtenez un message parse error, vérifiez votre syntaxe avec attention. Si vous ne pouvez rien y trouvez à redire, il est très probable que votre version de MySQL ne supporte pas encore cette fonctionnalité que vous essayez d'utiliser. Si vous utilisez la version courante de mySQL et que le manuel http://www.mysql.com/doc/ ne couvre pas la syntaxe que vous utilisez, c'est que MySQL ne supporte pas votre syntaxe. Dans ce cas, vos seules options sont d'implémenter vous même la syntaxe ou d'envoyez un message à pour proposer de l'implémenter.

    Si le manuel présente la syntaxe que vous utilisez, mais que vous avez une ancienne version du serveur MySQL, il est recommandé de vérifier l'historique d'évolution de MySQL pour savoir quand la syntaxe a été supportée. Dans ce cas, vous avez l'option de mettre à jour votre MySQL avec une version plus récente. See Annexe C, Historique des changements MySQL.

  • Si vous avez un problème tel que vos données semblent corrompues, ou que vous recevez constamment des erreurs lors d'accès à une table, vous devriez commencer par essayer de réparer votre table avec l'utilitaire de ligne de commande myisamchk ou les syntaxes SQL CHECK TABLE et REPAIR TABLE. See Chapitre 5, Administration du serveur.

  • Si vous avez des tables qui se corrompent facilement, il vous faut essayer de trouver quand et pourquoi cela arrive. Dans ce cas, le fichier mysql-data-directory/'hostname'.err peut contenir des informations pertinentes qu'il est bon d'inclure dans votre rapport de bogues. See Section 5.9.1, « Le log d'erreurs ». Normalement, mysqld ne doit jamais corrompre une table si il a été interrompu au milieu d'une mise à jour. Si vous pouvez trouvez la cause de l'arrêt de mysqld, il est bien plus facile pour nous de fournir un correctif. See Section A.1, « Comment déterminer ce qui pose problème ».

  • Si possible, téléchargez et installez la version la plus récente du serveur MySQL, et vérifiez si cela résout votre problème. Toutes les versions de MySQL sont testées à fond, et doivent fonctionner sans problème. Nous croyons à la compatibilité ascendante, et vous devriez pouvoir passer d'une version à l'autre facilement. See Section 2.1.2, « Choisir votre version de MySQL ».

Si vous disposez de l'accès au support client, contactez aussi le support client à , en plus de la liste de rapport de bogues, pour un traitement prioritaire.

Pour des informations sur les rapports de bogues avec MyODBC, voyez Section 25.1.1.9, « Rapporter des problèmes avec MYODBC ».

Pour des solutions aux problèmes les plus courants, voyez Annexe A, Problèmes et erreurs communes.

Lorsque des solutions vous sont envoyées individuellement et non pas à la liste, il est considéré comme bien vu de rassembler ces réponses et d'en envoyer un résumé sur le liste, de manière à ce que les autres en profitent aussi.

1.4.1.4 Conseils pour répondre sur la liste de diffusion

Si vous pensez que votre réponse peut avoir un intérêt général, vous pouvez envisager de l'envoyer sur la liste de diffusion, plutôt que de faire une réponse personnelle aux demandeurs. Essayez de rendre votre réponse aussi générale que possible, pour que suffisamment d'autres personnes puissent en profiter. Lorsque vous envoyez une réponse sur la liste, assurez vous qu'elle ne représente pas un doublon d'une réponse précédente.

Essayez de résumer l'essentiel de la question dans votre réponse. Ne vous croyez pas obligé de citer tout le message original.

Attention : n'envoyez pas de message avec le mode HTML activé ! De nombreux utilisateurs ne lisent pas leurs emails avec un navigateur.

1.4.2 Support de la communauté MySQL sur IRC (Internet Relay Chat)

En plus des différentes listes de diffusion MySQL, vous pouvez rencontrer des utilisateurs expérimentés sur IRC (Internet Relay Chat). Voici les meilleurs canaux, à notre connaissance :

  • freenode (voyez http://www.freenode.net/ pour les serveurs)

    • #mysql Principalement, des questions sur MySQL, mais les autres bases de données et le langage SQL sont aussi acceptés.

  • EFnet (voyez http://www.efnet.org/ pour les serveurs)

    • #mysql Questions sur MySQL.

Si vous recherchez un client IRC pour vous connecter à un réseau IRC, voyez donc X-Chat (http://www.xchat.org/). X-Chat est disponible sous Unix et sous Windows.

1.4.3 Support de la communauté MySQL sur les forums MySQL

La ressource ultime de support de la communauté sont les forums sur http://forums.mysql.com.

Il y a une large gamme de serveurs disponibles, regroupés par thèmes comme ceci :

  • Migration

  • Utilisation de MySQL

  • Connecteurs MySQL

  • MySQL Technology

  • Business

1.5 Quels standards respecte MySQL ?

Cette section présente comment MySQL interprète les standards SQL ANSI. Le serveur MySQL dispose de nombreuses extensions au standard ANSI et vous trouverez ici comment les exploiter. Vous trouverez aussi des informations sur les fonctionnalités manquantes de MySQL et comment y trouver des palliatifs.

Notre but n'est pas, sans une bonne raison, de restreindre les capacités de MySQL à un usage unique. Même si nous n'avons pas les ressources de développement à consacrer à toutes les opportunités, nous sommes toujours intéressés et prêts à aider ceux qui utilisent MySQL dans de nouveaux domaines.

Un de nos objectifs avec ce produit est de tendre à la compatibilité ANSI 99, mais sans sacrifier la vitesse ou la robustesse. Nous ne reculons pas devant l'ajout de nouvelle fonctionnalités au langage SQL, ou le support de fonctionnalités hors SQL, qui améliorent le confort d'utilisation de MySQL. La nouvelle interface de gestionnaires HANDLER de MySQL 4.0 est un exemple de cette stratégie. See Section 13.1.3, « Syntaxe de HANDLER ».)

Nous continuons de supporter les bases transactionnelles et non transactionnelles pour combler les besoins des sites web ou des applications à fort besoin d'archivage, ainsi que les applications critiques à très haute disponibilité.

Le serveur MySQL a été con¸u pour travailler avec des bases de taille moyenne (de 10 à 100 millions de lignes, ou des tables de 100 Mo) sur des systèmes de petite taille. Nous continuons d'améliorer MySQL pour qu'il fonctionne avec des bases gigantesques (tera-octets), tout en conservant la possibilité de compiler une version réduite de MySQL pour qu'il fonctionne sur des appareils embarqués ou nomades. L'architecture compacte de MySQL rend possible le support de ces applications si différentes, sans aucun conflit dans les sources.

Nous n'étudions pas le support du temps réel ou des bases de données en grappe (même si vous pouvez dores et déjà réaliser de nombreuses applications avec les services de réplication).

Nous ne croyons pas au support natif du XML en base, mais nous allons faire en sorte d'ajouter le support XML que réclame nos clients du coté client. Nous pensons qu'il est préférable de conserver le serveur central aussi ``simple et efficace'' que possible, et développer les bibliothèques qui gèrent la complexité du coté client. Cela fait partie de la stratégie que nous avons mentionné plus tôt, pour ne sacrifier ni la vitesse, ni la robustesse du serveur.

1.5.1 Quels standards suit MySQL ?

Nous nous dirigeons vers le support complet du standard ANSI SQL, mais sans aucune concession sur la vitesse ou la qualité du code.

ODBC niveau 0−3.51.

1.5.2 Sélectionner les modes SQL

Le serveur MySQL peut opérer avec différents modes SQL, et peut appliquer des modes différents pour chaque client. Cela permet aux applications d'adapter le comportement du serveur à ses attentes.

Le mode définit quelle syntaxe SQL MySQL doit supporter, et quel type de validations il doit effectuer sur les données. Cela facilite l'utilisation de MySQL dans différents environnements, et avec d'autres bases de données.

Vous pouvez configurer le mode SQL par défaut en lan¸ant le serveur mysqld avec l'option --sql-mode="modes". Depuis MySQL 4.1, vous pouvez aussi changer le mode après le lancement, en changeant la variable sql_mode avec la commande SET [SESSION|GLOBAL] sql_mode='modes'.

Pour plus d'informations sur les modes serveurs, voyez Section 5.2.2, « Le mode SQL du serveur ».

1.5.3 Exécuter MySQL en mode ANSI

Vous pouvez lancer mysqld en mode ANSI avec l'option de démarrage --ansi. See Section 5.2.1, « Options de ligne de commande de mysqld ».

Le mode ANSI revient à lancer le serveur avec les options suivantes (spécifiez la valeur de --sql_mode sur une seule ligne) :

--transaction-isolation=SERIALIZABLE
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
IGNORE_SPACE,ONLY_FULL_GROUP_BY

En MySQL version 4.1, vous pouvez arriver à la même configuration avec ces deux options (spécifiez la valeur de --sql_mode sur une seule ligne) :

SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET GLOBAL sql_mode = 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
IGNORE_SPACE,ONLY_FULL_GROUP_BY';

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

En MySQL version 4.1.1, les options sql_mode présentée ci-dessus peuvent être configurée avec :

SET GLOBAL sql_mode='ansi';

Dans ce cas, la valeur de la variable sql_mode prendre toute les options du mode ANSI. Vous pouvez vérifier le résultat comme ceci :

mysql> SET GLOBAL sql_mode='ansi';
mysql> SELECT @@global.sql_mode;
        -> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
            IGNORE_SPACE,ONLY_FULL_GROUP_BY,ANSI';

1.5.4 Extensions MySQL au standard SQL-92

Le serveur MySQL inclut des extensions que vous ne trouverez probablement pas dans les autres bases de données. Soyez prévenus que si vous les utilisez, votre code ne sera probablement pas portable sur d'autres serveurs SQL. Dans certains cas, vous pouvez écrire du code qui inclut des spécificités de MySQL, mais qui restent portables, en les incluant dans des commentaires de la forme /*! ... */. Dans ce cas, le serveur MySQL va analyser la chaîne et exécuter le code à l'intérieur de ces commentaires comme une commande normale, mais d'autres serveurs ignoreront ces commentaires. Par exemple :

SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...

Si vous ajoutez le numéro de version après le point d'exclamation ‘!’, la syntaxe sera exécutée uniquement si la version du serveur MySQL est égale ou plus récente que le numéro de version utilisé.

CREATE /*!32302 TEMPORARY */ TABLE t (a int);

Cela signifie que si vous avez la version 3.23.02 ou plus récente, le serveur MySQL va utiliser le mot réservé TEMPORARY.

Voici une liste des apports spécifiques de MySQL :

  • Organisation des données sur le disque

    MySQL fait correspondre à chaque base un dossier dans le dossier de données MySQL, et à chaque table des fichiers portant le même nom. Ceci a plusieurs implications :

    • Les noms des bases de données et des tables sont sensibles à la casse sur les systèmes d'exploitation qui ont des systèmes de fichiers sensibles à la casse (comme la plupart des systèmes Unix). See Section 9.2.2, « Sensibilité à la casse pour les noms ».

    • Vous pouvez utiliser les commandes systèmes standard pour sauver, renommer, déplacer, effacer et copier des tables. Par exemple, pour renommer une table, il suffit de renommer les fichiers .MYD, .MYI et .frm et de leur donner un nouveau nom.

    Les noms de bases, tables, index, colonnes ou alias peuvent commencer par des chiffres, mais ne peuvent pas être constitués uniquement de noms.

  • Syntaxe générale du langage

    • Les chaînes de caractères peuvent être soit délimitées par ‘"’, soit par ‘'’. Pas seulement par ‘'’.

    • L'utilisation du caractère de protection ‘\’.

    • Dans une requête SQL, vous pouvez accéder à des tables situées dans différentes bases de données, avec la syntaxe db_name.tbl_name. Certains serveurs SQL fournissent la même fonctionnalité, mais l'appellent un User space. Le serveur MySQL ne supporte par les espaces de nom de tables, comme dans : create table ralph.my_table...IN my_tablespace.

  • Syntaxe de commande SQL

  • Types de colonnes

    • Les types de colonnes MEDIUMINT, SET, ENUM et les types BLOB et TEXT.

    • Les attributs de champs AUTO_INCREMENT, BINARY, NULL, UNSIGNED et ZEROFILL.

  • Fonctions et opérateurs

    • Pour aider les utilisateurs qui viennent d'autres environnements SQL, le serveur MySQL supporte des alias de nombreuses fonctions. Par exemple, toutes les fonctions de chaînes de caractères supportent simultanément les syntaxes ANSI SQL et ODBC.

    • Le serveur MySQL comprend les opérateurs || et && comme opérateurs logiques OR et AND, comme en langage C. Pour le serveur MySQL, les opérateurs || et OR sont synonymes, ainsi que && et AND. En conséquence, MySQL ne supporte pas l'opérateur de concaténation de chaînes ANSI SQL ||. Utilisez plutôt la fonction CONCAT(). Comme CONCAT() prend un nombre illimité d'arguments, il est facile de convertir des expressions utilisant ||, pour qu'elles fonctionnent sur le serveur MySQL.

    • L'utilisation de COUNT(DISTINCT list)list contient plus d'un élément.

    • Toutes les comparaisons de chaînes sont insensibles à la casse par défaut, et l'ordre de tri est déterminé par le jeu de caractères courant (ISO-8859-1 Latin1 par défaut). Si vous en souhaitez un autre, il faut déclarer les colonnes avec l'attribut BINARY ou utiliser l'opérateur BINARY pour forcer les comparaisons à prendre en compte la casse, en fonction du jeu de caractères utilisé sur l'hôte du serveur MySQL.

    • L'opérateur % est synonyme de MOD(). C'est à dire que N % M est équivalent à MOD(N,M). % est supporté pour les programmeurs C, et pour la compatibilité avec PostgreSQL.

    • Les opérateurs =, <>, <= ,<, >=,>, <<, >>, <=>, AND, OR ou LIKE peuvent être utilisés pour les comparaisons de colonnes à gauche de la clause FROM dans les commandes SELECT. Par exemple :

      mysql> SELECT col1=1 AND col2=2 FROM tbl_name;
      
    • La fonction LAST_INSERT_ID(), qui retourne la plus récente valeur de colonne AUTO_INCREMENT. See Section 12.8.3, « Fonctions d'informations ».

    • LIKE est possible avec des colonnes numériques.

    • Les opérateurs d'expressions régulières étendus REGEXP et NOT REGEXP.

    • CONCAT() et CHAR() avec un argument ou plus de deux arguments. Avec le serveur MySQL, ces fonctions peuvent prendre n'importe quel nombre d'arguments.

    • Les fonctions BIT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD(), ENCRYPT(), MD5(), ENCODE(), DECODE(), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS() et WEEKDAY().

    • L'utilisation de la fonction TRIM() pour réduire les chaînes. L'ANSI SQL ne supporte que les suppressions de caractères uniques.

    • Les fonctions de groupe de la clause GROUP BY STD(), BIT_OR(), BIT_AND(), BIT_XOR() et GROUP_CONCAT(). See Section 12.9, « Fonctions et options à utiliser dans les clauses GROUP BY ».

Pour une liste hiérarchisée des nouvelles extensions qui seront ajoutées à MySQL, vous pouvez consulter la liste de tâche en ligne sur http://dev.mysql.com/doc/mysql/en/TODO.html. C'est la dernière liste qui est utilisée dans ce formulaire. See Section B.8, « Les évolutions de MySQL (la liste des tâches) ».

1.5.5 Différences entre MySQL et le standard SQL-92

Nous tâchons de rendre le serveur MySQL compatible avec le standard ANSI SQL, et le standard ODBC SQL, mais dans certains cas, MySQL se comporte différemment.

1.5.5.1 Sous-requêtes

MySQL 4.1 supporte les sous-requêtes et les tables dérivées (vues anonymes). Une ``sous-requête'' est une commande SELECT imbriquée dans une autre commande. Une ``table dérivée'' (vues anonymes) est une sous-requête placée dans une clause FROM d'une autre commande. See Section 13.1.8, « Sous-sélections (SubSELECT) ».

Pour les versions de MySQL antérieure à la 4.1, la plupart des sous-requêtes peuvent être réécrites avec des jointures et d'autres méthodes. Voyez Section 13.1.8.11, « Se passer des sous-requêtes avec les premières versions de MySQL » pour des exemples d'illustration.

1.5.5.2 SELECT INTO TABLE

Le serveur MySQL ne supporte pas encore l'extension Oracle SQL : SELECT ... INTO TABLE .... A la place, le serveur MySQL supporte la syntaxe ANSI SQL INSERT INTO ... SELECT ..., qui revient au même. See Section 13.1.4.1, « Syntaxe de INSERT ... SELECT ».

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

Alternativement, vous pouvez utiliser SELECT INTO OUTFILE... et CREATE TABLE ... SELECT.

Depuis la version 5.0, MySQL supporte SELECT ... INTO avec les variables serveur. La même syntaxe peut aussi être utilisée dans les procédures stockées, en utilisant les curseurs et les variables locales. See Section 19.2.9.3, « Syntaxe de SELECT ... INTO ».

1.5.5.3 Transactions et opérations atomiques

Le serveur MySQL (version 3.23 MySQL-max et toutes les versions 4.0 et plus récent) supporte les transactions avec les gestionnaires de tables InnoDB et BDB. InnoDB dispose aussi de la compatibilité ACID totale. See Chapitre 14, Moteurs de tables MySQL et types de table.

Toutefois, les tables non transactionnelles de MySQL telles que MyISAM exploitent un autre concept pour assurer l'intégrité des données, appelé ``opérations atomiques''. Les opérations atomiques disposent d'une bien meilleure protection des données pour des performances également accrues. Comme MySQL supporte les deux méthodes, l'utilisateur est capable de choisir celle qui correspond à ses besoins, suivant qu'il a besoin de vitesse ou de sécurité. Ce choix peut être fait table par table.

Comment exploiter les capacités de MySQL pour protéger l'intégrité des données, et comment ces fonctionnalités se comparent elles avec les méthodes transactionnelles ?

  1. En mode transactionnel, si votre application a été écrite en dépendant de l'appel de ROLLBACK au lieu de COMMIT dans les situations critiques, les transactions sont plus pratiques. Les transactions s'assurent que les modifications non achevées ou les activités corrosives ne sont pas archivées dans la base. Le serveur a l'opportunité d'annuler automatiquement l'opération, et votre base de données est sauve.

    Le serveur MySQL, dans la plupart des cas, vous permet de résoudre les problèmes potentiels en incluant de simples vérifications avant les modifications, et en exécutant des scripts simples pour vérifier l'intégrité de vos bases de données, ainsi que les incohérences, et pour réparer automatiquement les problèmes, ou encore vous alerter si une erreur est identifiée. Notez qu'en utilisant simplement le log de MySQL, ou en utilisant un log supplémentaire, vous pouvez normalement réparer à la perfection toutes les tables, sans aucune perte de données.

  2. Souvent, les modifications de données transactionnelles fatales peuvent être réécrites de manière atomique. En général, tous les problèmes d'intégrité que les transactions résolvent peuvent être corrigés avec la commande LOCK TABLES ou des modifications atomiques, qui assurent que vous n'aurez jamais d'annulation automatique de la base, ce qui est un problème commun des bases transactionnelles.

  3. Même un système transactionnel peut perdre des données si le serveur s'arrête. La différence entre les systèmes repose alors dans ce petit laps de temps où ils peuvent perdre des données. Aucun système n'est sécurisé à 100%, mais simplement ``suffisamment sécurisé''. Même Oracle, réputé pour être la plus sûre des bases de données transactionnelles, est montré du doigt pour perdre des données dans ces situations.

    Pour être tranquille avec MySQL, que vous utilisiez les tables transactionnelles ou pas, vous n'avez besoin que de sauvegardes et de logs de modifications. Avec ces deux outils, vous pourrez vous protéger de toutes les situations que vous pourriez rencontrer avec d'autres bases de données transactionnelles. De toute manière, il est bon d'avoir des sauvegardes, indépendamment de la base que vous utilisez.

La méthode transactionnelle a ses avantages et ses inconvénients. De nombreux utilisateurs et développeurs d'applications dépendent de la facilité de pallier un problème lorsqu'une annulation semble nécessaire ou presque. Cependant, même si vous êtes néophyte des opérations atomiques, ou plus familier avec les transactions, prenez en considération le gain de vitesse que les tables non transactionnelles offrent. Ces gains vont de 3 a 5 fois la vitesse des tables transactionnelles les plus rapides et les mieux optimisées.

Dans des situations où l'intégrité est de la plus grande importance, le serveur MySQL assure une intégrité du niveau des transactions, ou encore mieux avec les tables non transactionnelles. Si vous verrouillez les tables avec LOCK TABLES, toutes les modifications seront bloquées jusqu'à ce que la vérification d'intégrité soit faite (à comparer avec un verrou en écriture), les lectures et insertions sont toujours possibles. Les nouvelles lignes ne seront pas accessibles en lecture tant que le verrou n'aura pas été levé. Avec INSERT DELAYED, vous pouvez faire attendre les insertions dans une pile, jusqu'à ce que les verrous soit levés, sans que le client n'attende cette levée de verrou. See Section 13.1.4.2, « Syntaxe de INSERT DELAYED ».

``Atomique'', avec le sens que nous lui donnons, n'a rien de magique. Ce terme signifie simplement que vous pouvez être certain que lorsque vous modifiez des données dans une table, aucun autre utilisateur ne peut interférer avec votre opération, et qu'il n'y aura pas d'annulation automatique (ce qui pourrait arriver avec des tables transactionnelles si nous ne sommes pas trop soigneux). Le serveur MySQL garantit aussi qu'il n'y aura pas de lectures erronées.

Voici quelques techniques pour travailler avec des tables non transactionnelles :

  • Les boucles qui requièrent les transactions peuvent normalement être implémentées avec la commande LOCK TABLES, et vous n'avez nul besoin de curseur lorsque vous modifiez des lignes à la volée.

  • Pour éviter d'utiliser l'annulation ROLLBACK, vous pouvez adopter la stratégie suivante :

    1. Utilisez la commande LOCK TABLES ... pour verrouiller toutes les tables que vous voulez utiliser.

    2. Testez vos conditions.

    3. Modifiez si tout est correct.

    4. Utilisez UNLOCK TABLES pour libérer vos tables.

    Ceci est probablement une méthode bien plus rapide que ne le proposent les transactions, avec des annulations ROLLBACK possibles mais pas certaines. La seule situation que ce cas ne prend pas en compte est l'interruption du processus au milieu d'une mise à jour. Dans ce cas, tous les verrous seront levés, mais certaines modifications peuvent ne pas avoir été exécutées.

  • Vous pouvez aussi utiliser des fonctions pour modifier des lignes en une seule opération. Vous pouvez créer une application très efficace en utilisant cette technique :

    • Modifiez les champs par rapport à leur valeur actuelle.

    • Modifiez uniquement les champs que vous avez réellement changé.

    Par exemple, lorsque nous modifions les données d'un client, nous ne modifions que les données du client qui ont changé et nous vérifions uniquement si les données modifiées ou les données qui en dépendent ont changé comparativement aux données originales. Les tests sur les données modifiées sont faits avec la clause WHERE dans la commande UPDATE. Si la ligne a été modifiée, nous indiquons au client : "Some of the data you have changed has been changed by another user". En fran¸ais : "certaines données que vous voulez modifier ont été modifiées par un autre utilisateur". Puis nous affichons l'ancienne ligne et la nouvelle ligne, pour laisser l'utilisateur décider quelle version il veut utiliser.

    Cela nous conduit à un résultat proche du verrouillage de ligne, mais en fait, c'est bien mieux, car nous ne modifions que les colonnes qui en ont besoin, en utilisant des valeurs relatives. Cela signifie qu'une commande UPDATE typique ressemble à ceci :

    UPDATE tablename SET pay_back=pay_back+'relative change';
    
    UPDATE customer
      SET
        customer_date='current_date',
        address='new address',
        phone='new phone',
        dette=dette+'emprunt'
      WHERE
        customer_id=id AND address='old address' AND phone='old phone';
    

    Comme vous pouvez le voir, c'est très efficace, et fonctionne même si un autre client a modifié la valeur pay_back ou dette.

  • Dans de nombreuses situations, les utilisateurs ont souhaité les commandes ROLLBACK et/ou LOCK TABLES afin de gérer des identifiant uniques pour certaines tables. Ils peuvent être gérés bien plus efficacement en utilisant une colonne de type AUTO_INCREMENT, en corrélation avec la fonction LAST_INSERT_ID() ou la fonction C mysql_insert_id(). See Section 12.8.3, « Fonctions d'informations ». See Section 24.2.3.33, « mysql_insert_id() ».

    Vous pouvez éviter le verrouillage de ligne. Certaines situations le requièrent vraiment, mais elles sont rares. Les tables InnoDB supportent le verrouillage de ligne. Avec les tables MyISAM, vous pouvez utiliser une colonne de type sémaphore, et faire ceci :

    UPDATE tbl_name SET row_flag=1 WHERE id=ID;
    

    MySQL retournera 1 pour le nombre de lignes affectées si la ligne a été trouvée, car row_flag ne vaut pas déjà 1 dans la ligne originale.

    Vous pouvez comprendre la requête ci-dessus comme si le serveur MySQL avait utilisé la commande suivante :

    UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
    

1.5.5.4 Procédures stockées et triggers

Les procédures stockées sont implémentées en version 5.0. See Chapitre 19, Procédures stockées et fonctions.

Un trigger est une procédure stockée qui est activée lorsqu'un événement particulier survient. Par exemple, vous pouvez installer une procédure stockée qui est déclenchée dès qu'une ligne est effacée dans une table d'achat, pour que le client soit automatiquement effacé si tous ses achats sont effacés.

1.5.5.5 Les clés étrangères

En MySQL version 3.23.44 et plus récentes, les tables InnoDB supportent les vérifications d'intégrité référentielles. See Chapitre 15, Le moteur de tables InnoDB. Pour les autres types de tables, le serveur mySQL accepte la syntaxe FOREIGN KEY dans la commande CREATE TABLE, mais ne la prend pas en compte.

Pour les autres moteurs de stockage que InnoDB, MySQL analyse la clause FOREIGN KEY de la commande CREATE TABLE, mais ne l'utilise pas et ne la stocke pas. Dans le futur, l'implémentation va stocker cette information dans le fichier de spécifications de tables, pour qu'elle puisse être lue par mysqldump et ODBC. Ultérieurement, les contraintes de clé étrangères seront incluses dans les tables MyISAM.

Voici des avantages aux contraintes de clés étrangères :

  • En supposant que les relations soient proprement con¸ues, les clés étrangères rendent plus difficile pour un programmeur d'insérer des valeurs incohérentes dans la base.

  • La vérification centralisée de contraintes par le serveur de base de données rend inutiles l'application de ces vérifications du coté de l'application. Cela élimine la possibilité que d'autres applications ne fassent pas les vérifications de la même fa¸on que les autres.

  • L'utilisation des modifications et effacement en cascade simplifie le code du client.

  • Les règles de clés étrangères proprement con¸ues aident à la documentation des relations entre les tables.

Gardez bien en tête que ces avantages ont un coût supérieur pour le serveur de bases, qui doit effectuer les tests. Les vérifications supplémentaires affectent les performances, ce qui est parfois suffisamment rebutant pour des applications qui les éviteront. Certaines applications commerciales ont placé la logique de vérification dans l'application, pour cette raison.

MySQL donne aux développeurs de bases de données le choix de leur approche. Si vous n'avez pas besoin des clés étrangères, et que vous voulez éviter leur surcoût, vous pouvez choisir un autre type de table, comme MyISAM. Par exemple, les tables MyISAM sont extrêmement rapides pour les applications qui font essentiellement des opérations INSERT et SELECT, car elles peuvent être utilisées simultanément. See Section 7.3.2, « Problème de verrouillage de tables ».

Si vous décidez de ne pas tirer avantage des contraintes d'intégrité, vous devez garder en tête ces conseils :

  • En l'absence de vérification du coté du serveur, l'application doit se charger de ces vérifications. Par exemple, elle doit s'assurer que les lignes sont insérées dans le bon ordre, et que les lignes ne sont pas orphelines. Il faut aussi pouvoir rattraper une erreur au milieu d'une opération multiple.

  • Si la clause ON DELETE est la seule fonctionnalité nécessaire, notez que depuis MySQL version 4.0, vous pouvez utiliser des commandes DELETE multi-tables pour effacer les lignes dans plusieurs tables en une seule commande. See Section 13.1.1, « Syntaxe de DELETE ».

  • Un palliatif au manque de ON DELETE est d'ajouter la commande DELETE appropriée lorsque vous effacez des lignes dans une table qui dispose d'une clé étrangère. En pratique, c'est souvent plus rapide que d'utiliser les clés étrangères, et c'est plus portable.

Soyez conscient que l'utilisation des clés étrangères dans certaines circonstances peuvent conduire à des problèmes :

  • Les clés étrangères règlent des problèmes de cohérence, mais il est nécessaire de concevoir les contraintes correctement, pour éviter les contraintes circulaires, ou des cascades d'effacements incorrects.

  • Il n'est pas exceptionnel pour un administrateur de créer une topologie de relations qui rende difficile la restauration de bases à partir d'une sauvegarde. MySQL résout ce problème en vous permettant de désactiver temporairement les contraintes. See Section 15.7.4, « Contraintes de clés étrangères FOREIGN KEY ». Depuis MySQL 4.1.1, mysqldump génère un fichier d'export qui exploite cette possibilité de désactivation automatique à l'import.

Notez que les clés étrangères SQL sont utilisées pour assurer la cohérence des données, et non pas pour joindre des tables. Si vous voulez obtenir des résultats de tables multiples dans une commande SELECT, vous devez le faire avec une jointure :

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

See Section 13.1.7.1, « Syntaxe de JOIN ». See Section 3.6.6, « Utiliser les clefs étrangères ».

La syntaxe FOREIGN KEY sans ON DELETE ... est souvent utilisée par les applications ODBC pour produire automatiquement des clauses WHERE.

1.5.5.6 Les vues

Il est prévu d'implémenter les vues dans la version 5.0 ou 5.1 du serveur MySQL.

Historiquement, MySQL a été utilisé dans des applications et sur les systèmes Web, où l'auteur de l'application a un contrôle complet sur le système de base de données. L'utilisation a évolué au cours du temps, et de nombreux utilisateurs pensent maintenant que c'est important.

Les vues anonymes (tables dérivées, une sous-requête de la clause FROM de la commande SELECT) sont déjà disponibles en version 4.1.

Les vues sont la plupart du temps utiles pour donner accès aux utilisateurs à un ensemble de relations représentées par une table (en mode inaltérable). Beaucoup de bases de données SQL ne permettent pas de mettre à jour les lignes dans une vue, vous devez alors faire les mises à jour dans les tables séparées. See Section 5.5, « Règles de sécurité et droits d'accès au serveur MySQL ».

De nombreuses bases de permettent pas les modifications de vues, mais permettent les mises à jour dans des tables individuelles. Lors de la conception de notre système de vues, nous envisageons le support complet de la règle ``numéro 6 de Codd'' (autant que possible en SQL) : toutes les vues qui sont théoriquement modifiables, et doivent l'être en pratique.

1.5.5.7 '--' comme début de commentaire

Certaines bases de données SQL utilisent '--' comme début de commentaire. Le serveur MySQL utilise ‘#’. Vous pouvez aussi utiliser la syntaxe du langage C /* ceci est un commentaire */. See Section 9.5, « Syntaxe des commentaires ».

MySQL version 3.23.3 et plus récent supporte les commentaires de type '--', si ce commentaire est suivi d'un espace. Ceci est dû au fait que ce type de commentaire a causé beaucoup de problèmes avec les requêtes générées automatiquement, qui contiennent du code tel que celui-ci, où nous insérons automatiquement la valeur du paiement dans la table !payment! :

UPDATE tbl_name SET credit=credit-!payment!

Pensez à ce qui se passe lorsque la valeur de payment est négative, comme -1 :

UPDATE account SET credit=credit--1

credit--1 est une expression légale en SQL mais -- est interprété comme un commentaire et la fin de l'expression est ignorée. Le résultat est que la commande prend une signification complètement différente :

UPDATE account SET credit=credit

La commande ne produit aucun changement! Cela montre que l'utilisation des commentaires de type '--' peuvent avoir des conséquences graves.

En utilisant notre implémentation des commentaires avec le serveur MySQL version 3.23.3 et plus récent, 1-- ceci est un commentaire ne pose pas ce type de problème.

Une autre fonctionnalité supplémentaire est que le client en ligne de commande mysql supprime toutes les lignes qui commencent par '--'.

Les informations suivantes sont destinées aux utilisateurs de MySQL avec des versions antérieures à la version 3.23.3 :

Si vous avez un programme SQL dans un fichier texte qui contient des commentaires au format '--', il est recommandé d'utiliser l'utilitaire replace pour assurer la conversion en caractères ‘#’ :

shell> replace " --" " #" < text-file-with-funny-comments.sql \
         | mysql database

au lieu du classique :

shell> mysql database < text-file-with-funny-comments.sql

Vous pouvez aussi éditer le fichier de commande ``lui-même'' pour remplacer les commentaires '--' par des commentaires ‘#’ :

shell> replace " --" " #" -- text-file-with-funny-comments.sql

Puis, rétablissez-les avec :

shell> replace " #" " --" -- text-file-with-funny-comments.sql

1.5.6 Comment MySQL gère les contraintes

Comme MySQL permet de travailler avec des moteurs de tables transactionnelles ou pas, les contraintes sont gérées un peu différemment sur MySQL que sur les autres bases de données.

Nous devons gérer le cas où vous avez modifié beaucoup de lignes avec une table non-transactionnelles, qui ne peut annuler les modifications en cas d'erreur.

La philosophie de base est d'essayer de détecter autant d'erreur que possible au moment de la compilation, mais d'essayer de réparer les erreurs à l'exécution. Nous y arrivons dans la plupart des cas, mais pas tout le temps. See Section B.8.3, « Ce qui doit être fait dans un futur proche ».

La solution de base de MySQL est d'interrompre la commande au milieu, ou de faire de son mieux pour réparer le problème et continuer.

Voici ce qui se passe dans les différents types de contraintes.

1.5.6.1 Contrainte avec PRIMARY KEY / UNIQUE

Normalement, vous allez obtenir une erreur lorsque vous essayerez d'insérer INSERT ou modifier UPDATE une ligne qui causera une violation de clé primaire, unique ou étrangère. Si vous utilisez un moteur transactionnelle, comme InnoDB, MySQL va immédiatement annuler la transaction. Si vous utilisez un moteur non-transactionnel, MySQL va s'arrêter à la mauvaise ligne, et laisser les dernières lignes intactes.

Pour rendre la vie plus facile, MySQL a ajouté le support de l'option IGNORE aux commandes qui peuvent rencontrer un problème de clé (comme INSERT IGNORE ...). Dans ce cas, MySQL va ignorer les problèmes de clé et la ligne, et continuer à traiter les lignes suivantes. Vous pouvez obtenir la liste des alertes avec la fonction mysql_info() et, dans les prochaines versions de MySQL 4.1, vous pourrez aussi les voir avec la commande SHOW WARNINGS. See Section 24.2.3.31, « mysql_info() ». See Section 13.5.3.19, « SHOW WARNINGS | ERRORS ».

Notez que pour le moment, seules les tables InnoDB supportent les clés étrangères. See Section 15.7.4, « Contraintes de clés étrangères FOREIGN KEY ». Le support des clés étrangères des tables MyISAM sont prévues pour la version 5.0.

1.5.6.2 Contraintes sur les valeurs invalides

Pour être capable de supporter facilement les tables non-transactionnelles, tous les champs de MySQL ont des valeurs par défaut.

Si vous insérez une valeur ``invalide'' dans une colonne, comme NULL dans une colonne NOT NULL, ou une valeur numérique trop grand dans une colonne numérique, MySQL inscrit dans la colonne la ``meilleure valeur possible'', sans produire d'erreur :

  • Si vous stockez un chiffre hors de l'intervalle de validité d'une colonne numérique, MySQL stocke à la place zéro, la plus petite valeur possible, ou bien la plus grande valeur possible.

  • Pour les chaînes, MySQL stocke la chaîne vide ou bien la plus grande chaîne qui peut être stockée dans cette colonne.

  • Si vous essayez de stocker une chaîne qui ne commence pas par un chiffre dans une colonne numérique, MySQL stocke 0.

  • Si vous essayez de stocker NULL dans une colonne qui n'accepte pas la valeur NULL, MySQL stocke 0 ou '' (la chaîne vide). Ce dernier comportement peut, pour des insertions de ligne unique, être modifié par l'option de compilation -DDONT_USE_DEFAULT_FIELDS. See Section 2.4.2, « Options habituelles de configure ». Cela fait que les commandes INSERT génèreront une erreur à moins que vous ne spécifiez explicitement les valeurs pour toutes les colonnes qui requièrent une valeur non-NULL.

  • MySQL vous permet de stocker des dates incorrectes dans les colonnes de type DATE et DATETIME (comme '2000-02-31' ou '2000-02-00'). L'idée est que ce n'est pas le travail du serveur SQL de valider les dates. Si MySQL peut stocker une valeur et relire exactement la même valeur, MySQL la stockera. Si la date est totalement erronée (hors de l'intervalle de validité), la valeur spéciale '0000-00-00' est stockée dans la colonne.

La raison de cette règle ci-dessus est que nous ne pouvons pas vérifier ces conditions avant que la requête ne soit exécutée. Si nous rencontrons un problème après la modification de quelques lignes, nous ne pourront pas annuler la modification, car la table ne le supporte peut-être pas. L'alternative qui consiste à s'arrêter c'est pas envisageable non plus, car nous aurions alors fait la moitié du travail, ce qui sera alors le pire scénario. Dans ce cas, il vaut mieux faire "du mieux possible", et continuer comme si rien n'était arrivé. En MySQL 5.0, nous envisageons d'améliorer cela en fournissant des alertes de conversions automatique, ainsi qu'une option pour vous permettre d'annuler la commande si elle n'utilise que des tables transactionnelles.

Ceci signifie qu'il ne faut pas compter sur MySQL pour vérifier le contenu des champs, mais de gérer cela au niveau de l'application.

1.5.6.3 Constante avec ENUM et SET

En MySQL 4.x ENUM n'est pas une véritable contrainte, mais simplement un moyen plus efficace de stocker des champs qui peuvent prendre un nombre limité de valeurs différentes. C'est la même raison pour laquelle NOT NULL n'est pas respecté.

Si vous insérez une valeur invalide dans un champs ENUM, la colonne prendra la valeur réservée 0, qui sera représentée par une chaîne vide, en mode chaîne. See Section 11.4.4, « Le type ENUM ».

Si vous insérez une mauvais option dans un ensemble SET, la valeur sera ignorée. See Section 11.4.5, « Le type SET ».

1.5.7 Erreurs connues, et limitations de MySQL

1.5.7.1 Erreurs connues en 3.23 et corrigées ultérieurement

Les erreurs suivantes sont connues mais restent non corrigées en MySQL3.23, car pour les corriger, il nous faudrait modifier trop de code : cela risquerait d'introduire des bugs bien pire. Ces bogues sont considérés comme ``non nuisibles'' ou ``supportables''.

  • Il est possible de rencontrer un blocage en utilisant la commande LOCK TABLE sur de multiples tables, puis, avec la même connexion, faire un DROP TABLE sur l'une d'entre elle, alors qu'un autre thread essai de verrouiller la table. Il est toutefois possible d'utiliser la commande KILL sur l'un des threads en question, pour résoudre ce problème. Corrigé en 4.0.12.

  • SELECT MAX(key_column) FROM t1,t2,t3... où l'une des tables est vide ne retourne pas NULL mais plutôt le valeur maximale de la colonne. Corrigé en 4.0.11.

  • DELETE FROM heap_table sans clause WHERE ne fonctionne pas sur une table HEAP.

1.5.7.2 Erreurs de la version 4.0, corrigées plus tard

Voici la liste des bugs/erreurs qui ne sont pas corrigées en MySQL 4.0 car cette correction prendrait trop de manipulations, qui risqueraient d'introduire encore d'autres bugs. Les bugs sont aussi classé comme ``non fatal'' ou ``supportable.''

  • Dans une UNION, le premier SELECT définit le type, et les propriétés max_length et NULL pour les colonnes du résultat. En MySQL 4.1.1, ces propriétés sont définies comme la combinaison de toutes les parties de l'UNION.

  • Dans une commande DELETE sur de nombreuses tables, vous ne pouvez pas utiliser les alias pour effacer dans une table. Ceci est corrigé en MySQL 4.1.

  • Vous ne pouvez pas mélanger des clauses UNION ALL et UNION DISTINCT dans la même requête. Si vous utilisez l'option ALL dans une des clauses UNION, elle est utilisée pour toutes ces clauses.

1.5.7.3 Erreurs de la version 4.1 corrigées dans d'autres versions de MySQL

Les erreurs suivantes sont des erreurs connues ou bogues qui n'ont pas été corrigés en MySQL 4.1 car leur correction imposerait des modifications trop importantes au code, et conduirait à l'introduction potentiels de bogues bien pires. Ces bogues sont classés comme ``not fatal'' ou ``tolérables''.

  • VARCHAR et VARBINARY suppriment les espaces de fin de chaîne. (Corrigé en version 5.0.3).

1.5.7.4 Bugs connus / limitations de MySQL

Les problèmes suivants sont connus, et sont en tête de liste pour être corrigés :

  • Il n'est pas possible de mélanger UNION ALL et UNION DISTINCT dans la même requête. Si vous utilisez ALL pour UNION alors il faut l'utiliser partout.

  • Si un utilisateur a une transaction longue, et qu'un autre utilisateur efface une table qui est modifiée par la même transaction, il y a quelques chances que le log binaire n'enregistre pas la commande DROP TABLE avant que la table ne soit utilisée par la transaction elle-même. Nous envisageons de corriger cela en version 5.0, en for¸ant DROP TABLE a attendre jusqu'à ce que la table ne soit plus utilisée par la transaction.

  • Lors de l'insertion d'un grand entier (valeur entre 2^63 et 2^64-1) dans une colonne de type décimal ou chaîne, il sera enregistré comme une valeur négative, car le nombre est considéré comme un entier signé dans ce contexte. Il est prévu de corriger cela en 4.1.

  • FLUSH TABLES WITH READ LOCK ne bloque pas CREATE TABLE ou COMMIT, ce qui peut causer des problèmes avec la position du log lors d'une sauvegarde complète des tables et du log binaire.

  • ANALYZE TABLE sur une table de type BDB, peut rendre la table inutilisable, dans certains cas, jusqu'au prochain redémarrage de mysqld. Lorsque cela survient, vous rencontrez les erreurs suivantes dans le fichier d'erreur MySQL :

    001207 22:07:56  bdb:  log_flush: LSN past current end-of-log
    
  • MySQL accepte les parenthèses dans la clause FROM, mais les ignore silencieusement. La raison de l'absence d'erreur est que de nombreux clients qui génèrent des requêtes, ajoutent les parenthèses dans la clause FROM même si elles sont inutiles.

  • Concaténer plusieurs RIGHT JOINS ou combiner des jointures LEFT et RIGHT dans la même requête ne donnera pas de résultat correct si MySQL ne génère que des lignes NULL pour la table précédent le LEFT ou avant la jointure RIGHT. Cela sera corrigé en 5.0, en même temps que le support des parenthèses pour la clause FROM.

  • N'exécutez pas de commande ALTER TABLE sur une table BDB sur laquelle vous avez exécuté des transactions à plusieurs commandes, jusqu'à ce que ces transactions soient achevées : la transaction sera probablement ignorée.

  • ANALYZE TABLE, OPTIMIZE TABLE et REPAIR TABLE peuvent causer des problèmes sur les tables avec lesquelles vous utilisez la commande INSERT DELAYED.

  • Faire un LOCK TABLE ... et FLUSH TABLES ... ne vous garantit pas qu'il n'y a pas une transaction en court sur la table.

  • Les tables BDB sont lentes à ouvrir. Si vous avez de nombreuses tables BDB dans une base, cela prendra du temps au client mysql pour accéder à la base si vous n'utilisez pas l'option -A, ou si vous utilisez la commande rehash. C'est particulièrement vrai si vous n'avez pas de cache de table important.

  • La réplication utilise un log de niveau requête : le maître écrit les requêtes exécutées dans le log binaire. C'est une méthode de log rapide, compacte et efficace, qui fonctionne à la perfection dans la plupart des situations. Même si nous n'avons jamais vu d'occurrence de ce problème, il est théoriquement possible pour les données du maître et de l'esclave de différer si une requête non-déterministe est utilisée pour modifier les données, c'est à dire si elle est laissé au bon vouloir de l'optimiseur, ce qui n'est pas une bonne pratique même sans la réplication. Par exemple :

    • Des commandes CREATE ... SELECT ou INSERT ... SELECT qui insèrent zéro ou NULL valeurs dans la colonne AUTO_INCREMENT.

    • DELETE si vous effacez des lignes dans une table qui a une propriété ON DELETE CASCADE.

    • Les commandes REPLACE ... SELECT, INSERT IGNORE ... SELECT, si vous avez des clés en double, dans les données insérées.

    IF et seulement si ces requêtes n'ont pas de clause ORDER BY, qui garantisse un ordre déterministe.

    Effectivement, par exemple, pour les commandes INSERT ... SELECT sans clause ORDER BY, le SELECT peut retourner les lignes dans un ordre différent, ce qui aura pour résultat de donner des rangs différents et donnera des numéros d'identifiants différents aux colonnes auto_increment), en fonction des choix fait par les optimiseurs du maître et de l'esclave. Une requête sera optimisée différemment sur l'esclave et sur le maître si :

    • Les fichiers utilisés par les deux requêtes ne sont pas exactement les mêmes. Par exemple, OPTIMIZE TABLE a été exécuté sur le maître et pas sur l'esclave (pour corriger cela, depuis MySQL 4.1.1, OPTIMIZE, ANALYZE et REPAIR sont aussi écrits dans le log binaire).

    • La table est stockées sur un moteur de stockage différent sur le maître et sur l'esclave : c'est possible d'utiliser des moteurs de tables différents. Par exemple, le maître utiliser InnoDB et l'esclave MyISAM, car l'esclave a moins d'espace disque.

    • Les tailles de buffer MySQL (key_buffer_size, etc.) sont différentes sur le maître et sur l'esclave.

    • Le maître et l'esclave utilisent des versions différentes de MySQL, et le code de l'optimiseur est différent entre ces versions.

    Ce problème peut aussi affecter la restauration de base, utilisant mysqlbinlog ou mysql.

    Le plus simple pour éviter ces problèmes dans tous les cas est d'ajouter toujours une clause ORDER BY aux requêtes non-déterministe, pour s'assure que les lignes sont traitées dans le même ordre. Dans le futur, MySQL va ajouter automatiquement une clause ORDER BY si nécessaire.

Les problèmes suivants sont connus et seront corrigés en leur temps :

  • mysqlbinlog n'efface pas les fichiers temporaires laissés après une commande LOAD DATA INFILE. See Section 8.5, « mysqlbinlog, Exécuter des requêtes dans le log binaire ».

  • Il n'est pas possible de renommer une table temporaire.

  • Lors de l'utilisation de la fonction RPAD, ou de toute autre fonction de chaîne qui peut ajouter des espaces à droite de la chaîne, dans une requête qui utilise une table temporaire pour la résolution, alors toutes les chaînes verront leurs espaces terminaux être supprimés. Voici un exemple d'une telle requête :

    SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

    Le résultat final de ceci est que vous ne pourrez pas obtenir les espaces à gauche dans ces chaînes.

    Le comportement décrit ci-dessus existe dans toutes les versions de MySQL.

    La raison à cela est due au fait que les tables de type HEAP, qui sont utilisées en premier comme table temporaires, ne sont pas capables de gérer des colonnes de type VARCHAR.

    Ce comportement sera corrigé dans l'une des versions de la série des 4.1.

  • A cause de la méthode de stockage des tables de définitions de fichiers, il n'est pas possible d'utiliser le caractère 255 (CHAR(255)) dans les noms des tables, colonnes ou énumérations. Il est prévu de corriger de problème dans les versions version 5.1, lorsque nous aurons établi un nouveau format de définition des fichiers.

  • Lorsque vous utilisez la commande SET CHARACTER SET, il n'est pas possible d'utiliser les caractères traduits dans les noms de bases, de tables ou de colonnes.

  • Il n'est pas possible d'utiliser _ ou % avec la commande ESCAPE dans la clause LIKE... ESCAPE.

  • Si vous avez une colonne de type DECIMAL avec un nombre stocké dans un autre format (+01.00, 1.00, 01.00), GROUP BY peut considérer ces valeurs comme différentes.

  • Lorsque DELETE FROM merge_table est utilisé sans la clause WHERE, elle va simplement effacer le fichier de la table, et ne pas effacer les tables associées.

  • Vous ne pouvez pas compiler le serveur dans un autre dossier lorsque vous utilisez les MIT-pthreads. Comme cela requiert une modification des MIT-pthreads, nous ne corrigerons pas ce problème. See Section 2.4.5, « Notes relatives aux MIT-pthreads ».

  • Les valeurs de type BLOB ne peuvent pas être utilisées ``correctement'' dans les clauses GROUP BY ou ORDER BY ou DISTINCT. Seuls, les max_sort_length premiers octets (par défaut, 1024) seront utilisés pour les comparaisons de BLOB. Ceci peut être modifié avec l'option -O max_sort_length de mysqld. Un palliatif à ce problème est d'utiliser une sous partie de chaîne : SELECT DISTINCT LEFT(blob,2048) FROM tbl_name.

  • Les calculs sont faits avec des BIGINT ou DOUBLE (les deux sont normalement de 64 bits). La précision dépend alors de la fonction utilisée. La règle générale est que les fonctions de bits utilisent la précision des BIGINT, IF et ELT() utilisent la précision des BIGINT ou DOUBLE, et les autres utilisent la précision des DOUBLE. Il faut donc éviter d'utiliser les entiers non signés de grande taille, surtout s'ils dépassent la taille de 63 bits (9223372036854775807) pour toute autre fonction que les champs de bits ! La version 4.0 gère bien mieux les BIGINT que la 3.23.

  • Toutes les colonnes de type chaînes, hormis les BLOB et TEXT, voient automatiquement leurs caractères blancs finaux supprimés. Pour le type CHAR c'est correct, et c'est considéré comme une fonctionnalité par la norme ANSI SQL92. Le hic est que pour le serveur MySQL les colonnes VARCHAR sont traitées de la même fa¸on.

  • Vous ne pouvez avoir que des colonnes de taille 255 pour les ENUM et SET.

  • Avec les fonctions d'agrégation MIN(), MAX() et compagnie, MySQL compare actuellement les colonnes de type ENUM et SET par leur valeur de chaîne, plutôt que par leur position relative dans l'ensemble.

  • safe_mysqld redirige tous les messages de mysqld vers le log mysqld. Le problème est que si vous exécutez mysqladmin refresh pour fermer et ouvrir à nouveau l'historique, stdout et stderr sont toujours redirigés vers l'ancien log. Si vous utilisez --log, vous devriez éditer safe_mysqld pour envoyer les messages vers 'hostname'.err au lieu de 'hostname'.log, de fa¸on à pouvoir facilement récupérer la place de l'ancien log, en effa¸ant les vieux, et en exécutant mysqladmin refresh.

  • Dans la commande UPDATE, les colonnes sont modifiées de gauche à droite. Si vous faite référence à une colonne modifiée, vous obtiendrez sa valeur modifiée, plutôt que sa valeur originale. Par exemple :

    mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
    

    Cette commande va modifier la colonne KEY avec 2 au lieu de 1.

  • Vous ne pouvez pas utiliser les tables temporaires plus d'une fois dans la même requête. Par exemple, cette commande ne fonctionne pas :

    mysql> SELECT * FROM temporary_table, temporary_table AS t2;
    
  • RENAME ne fonctionne pas avec les tables TEMPORARY, ou les tables utilisées dans un rassemblement (MERGE).

  • L'optimiseur peut gérer la clause DISTINCT différemment si vous utilisez des colonnes cachées dans une jointure. Dans une jointure, les colonnes cachées sont comptées comme une partie du résultat (même si elles ne sont pas montrées), tandis que dans les requêtes normales, les colonnes cachées ne participent pas aux DISTINCT. Nous allons probablement modifier ceci dans le futur, pour ne jamais exploiter les colonnes cachées avec DISTINCT.

    Voici un exemple :

    SELECT DISTINCT mp3id FROM band_downloads
           WHERE userid = 9 ORDER BY id DESC;
    

    et

    SELECT DISTINCT band_downloads.mp3id
           FROM band_downloads,band_mp3
           WHERE band_downloads.userid = 9
           AND band_mp3.id = band_downloads.mp3id
           ORDER BY band_downloads.id DESC;
    

    Dans le second cas, MySQL 3.23.x pourrait vous donner deux lignes identiques dans le résultat (car les lignes cachées id diffèrent).

    Notez que cela n'arrive que pour les requêtes où vous n'avez pas de colonnes de la clause ORDER BY dans le résultat, ce que vous ne pourriez pas faire en ANSI SQL.

  • Comme le serveur MySQL vous permet de travailler avec des tables qui ne supportent pas les transactions, et donc, l'annulation rollback, certains comportements sont différents avec MySQL d'avec d'autres serveurs SQL. C'est nécessaire pour s'assurer que MySQL n'a jamais besoin d'annuler une commande SQL. Cela peut sembler un peu étrange au moment où les colonnes doivent être vérifiées par l'application, mais cela vous fournit une accélération notable, à cause d'optimisations qui ne pourraient pas avoir lieu ailleurs.

    Si vous donnez une valeur incorrecte à une colonne, MySQL va stocker le meilleur code possible dans la colonne, au lieu d'annuler la transaction :

    • Si vous essayez de stocker une valeur qui est hors de l'intervalle de validité dans une colonne numérique, MySQL va stocker la plus petite ou la plus grande valeur qu'il connaisse dans cette colonne.

    • Si vous essayez de stocker une chaîne qui ne commence pas par un chiffre dans une colonne numérique, MySQL va stocker 0.

    • Si vous essayez de stocker la valeur NULL dans une colonne qui n'accepte pas la valeur NULL, le serveur MySQL va stocker 0 ou '' (chaîne vide) à la place : ce comportement peut être modifié avec l'option de compilation -DDONT_USE_DEFAULT_FIELDS).

    • MySQL vous autorise le stockage de dates erronées dans les colonnes de type DATE et DATETIME (comme 2000-02-31 ou 2000-02-00). L'idée est que ce n'est pas au serveur SQL de faire le travail de validation. Si MySQL peut stocker une date, et relire exactement cette date, alors MySQL va stocker cette date. Si la date est totalement fausse (hors de l'intervalle de validité du serveur), la valeur spéciale 0000-00-00 sera utilisée.

    • Si vous utilisez une valeur non supportée avec une colonne de type ENUM, la valeur stockée sera la chaîne vide, de valeur numérique 0.

    • Si vous utilisez une valeur invalide dans une colonne de type SET, la valeur sera ignorée.

  • Si vous exécutez une PROCEDURE sur une requête qui retourne un résultat vide, dans certains cas, PROCEDURE ne transformera pas les colonnes.

  • La création de table de type MERGE ne vérifie pas si les tables sous-jacentes sont de type compatible.

  • Le serveur MySQL ne supporte pas encore les valeurs Server NaN, -Inf et Inf pour les doubles. Utiliser ces valeurs générera des problèmes lorsque vous essayerez d'exporter et d'importer des données. Comme solution temporaire, vous pouvez remplacer NaN par NULL (si possible) et -Inf et Inf par les valeurs maximales possibles des colonnes double.

  • Si vous utilisez la commande ALTER TABLE pour ajouter un index de type UNIQUE à un table utilisée dans un rassemblement de tables MERGE, puis que vous utilisez ALTER TABLE pour ajouter un index normal à la table MERGE, l'ordre des clés sera différent pour les tables s'il y avait déjà une ancienne clé qui n'était pas unique. Ceci est dû au fait que ALTER TABLE place les clés UNIQUE avant les clés normales, pour être capable de détecter les clés doublons plus vite.

Les bogues suivants sont connus dans les anciennes versions de MySQL :

  • Vous pouvez obtenir un thread gelé si vous utilisez la commande DROP TABLE sur une table qui fait partie des tables verrouillées par LOCK TABLES.

  • Dans les cas suivants, vous pouvez obtenir un crash :

    • Le gestionnaire d'insertions retardées a déjà des insertions en attente pour une table.

    • LOCK table avec WRITE.

    • FLUSH TABLES.

  • Pour les versions de MySQL avant la 3.23.2, une commande UPDATE qui modifiait une clé avec la clause WHERE sur la même clé, pouvait échouer car la même clé était utilisée pour rechercher les lignes et la même ligne pouvait être trouvée plusieurs fois :

    UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;
    

    Un palliatif est :

    MySQL> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;
    

    Cela fonctionnera, car MySQL ne va pas utiliser d'index sur une expression dans la clause WHERE.

  • Avant la version 3.23 de MySQL, tous les types numériques étaient traités comme des champs à virgule fixe. Cela signifie que vous deviez spécifier le nombre de décimales que le champ devait avoir. Tous les résultats étaient retournés avec le nombre correct de décimales.

Pour les bogues spécifiques aux systèmes d'exploitation, voyez la section sur la compilation et le port. See Section 2.4, « Installation de MySQL avec une distribution source ». See Annexe D, Port vers d'autres systèmes.