Manuel de référence MySQL 5.0

• Amélioration des performances

  • MySQL 4.0 dispose d'un cache de requêtes qui peut accélérer grandement vos applications qui utilisent souvent les mêmes requêtes. Voir Section 5.11, « Cache de requêtes MySQL »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é

  • La nouvelle bibliothèque Embedded Server (au lieu de client/serveur) peut être facilement utilisée pour créer des applications indépendantes ou intégrées. Voir Section 1.3.1.2, « MySQL Server intégré (embedded) »1.3.1.2. MySQL Server intégré (embedded).

• 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. Voir Chapitre 15, Le moteur de tables InnoDBChapitre 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 textes, 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 quelle langue. Cela ouvre la possibilité de nombreuses applications avec MySQL Serveur. Voir Section 12.6, « Recherche en texte intégral (Full-text) dans MySQL »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. Voir Section 2.2.14, « Installer MySQL sur NetWare »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. Voir Section 13.5.2.8, « Syntaxe de SET »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 comptage de lignes sans utiliser la clause LIMIT.

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

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 hautes performances, et les bases de données autonomes sur CD-ROM.

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. Voir Section 24.2.16, « libmysqld, la bibliothèque du serveur embarqué MySQL »24.2.16. libmysqld, la bibliothèque du serveur embarqué MySQL.

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 Voir Section B.8.1, « Nouvelles fonctionnalités prévues pour la version 5.0 »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 les procédures stockées, seront disponibles en MySQL 5.0. Voir Section B.8.1, « Nouvelles fonctionnalités prévues pour la version 5.0 »B.8.1. Nouvelles fonctionnalités prévues pour la version 5.0.

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

  • Une sous-requête est une commande SELECT imbriquée dans une autre requête. Une table dérivée (une vue anonyme) est une sous-requête dans une clause FROM d'une autre commande. Voir Section 13.1.8, « Sous-sélections (SubSELECT) »13.1.8. Sous-sélections (SubSELECT).

• Accélération

  • Protocole binaire plus rapide, avec préparation des commandes et paramétrage. Voir Section 24.2.4, « Fonctions C de commandes préparées »24.2.4. Fonctions C de commandes préparées.

  • Indexation BTREE pour les tables HEAP, ce qui améliore significativement le temps de réponse pour les recherches non exactes.

• 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). Voir Chapitre 18, Données spatiales avec MySQLChapitre 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. Voir Section 13.5.3.19, « SHOW WARNINGS | ERRORS »13.5.3.19. SHOW WARNINGS | ERRORS.

• Internationalisation

  • Pour supporter notre base d'utilisateurs en pleine croissance, et leur configuration locale, 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 particulier pour les sites multilangues.

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

• Améliorations d'ergonomie

  • En réponse à la demande populaire, nous avons ajouté une commande HELP command côté 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. Voir Section 24.2.9, « Gestion des commandes multiples avec l'interface C »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. Voir Section 13.1.4, « Syntaxe de INSERT »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. Voir Section 12.9, « Fonctions et options à utiliser dans les clauses GROUP BY »12.9. Fonctions et options à utiliser dans les clauses GROUP BY.

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

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 soient 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 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). Voir Section 1.4.1.3, « Comment rapporter un bogue ou un problème »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és 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és 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.

L'énumération suivante présente diverses autres listes de diffusions consacrées à 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é.

• <>

  Une liste de diffusion française.

• <>

  Une liste de diffusion coréenne. Envoyez un message à subscribe mysql your@e-mail.address.

• <>

  Une liste de diffusion allemande. Envoyez un message à subscribe mysql-de your@e-mail.address. Vous aurez plus d'informations sur cette liste à http://www.4t2.com/mysql/.

• <>

  Une liste de diffusion portugaise. Envoyez un message à subscribe mysql-br your@e-mail.address.

• <>

  Une liste de diffusion espagnole. Envoyez un message à subscribe mysql your@e-mail.address.

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

• étudiez 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 modifications (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.

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.

Écrire un bon rapport de bogue requiert de la patience, et le faire dès le début épargnera votre temps et le nôtre. 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 gaspilliez 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 binaires, 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é critique 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é 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é à 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 compilation 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. Voir Section D.1.6, « Faire une batterie de tests lorsque vous faites face à un problème de table corrompue »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. Voir Section 25.1.1.9, « Rapporter des problèmes avec MYODBC »25.1.1.9. Rapporter des problèmes avec MYODBC.

Pensez aussi que de nombreuses 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 importante. 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. Voir Section D.1.5, « Utilisation des fichiers de log pour trouver d'où viennent les erreurs de mysqld »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ées 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 vôtre.

• 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 lignes 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 chances 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) :

   

  Sélectionnez

  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 source 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 pour ê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-la via ftp sur le site de ftp://support.mysql.com/pub/mysql/secret/ [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é aux 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/ [ftp://support.mysql.com/pub/mysql/secret/]. Si les données sont vraiment ultrasecrè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 pour quoi 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 patch ne fonctionne pas, même s'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 bord 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 épuisé 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 trouver à 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'envoyer 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. Voir Annexe C, Historique des changements MySQLAnnexe 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. Voir Chapitre 5, Administration du serveurChapitre 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. Voir Section 5.9.1, « Le log d'erreurs »5.9.1. Le log d'erreurs. Normalement, mysqld ne doit jamais corrompre une table s'il a été interrompu au milieu d'une mise à jour. Si vous pouvez trouver la cause de l'arrêt de mysqld, il est bien plus facile pour nous de fournir un correctif. Voir Section A.1, « Comment déterminer ce qui pose problème »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. Voir Section 2.1.2, « Choisir votre version de MySQL »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 rapports 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 »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 communesAnnexe 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 la liste, de manière à ce que les autres en profitent aussi.

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.

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. Voir Section 13.1.8, « Sous-sélections (SubSELECT) »13.1.8. Sous-sélections (SubSELECT).

Pour les versions de MySQL antérieures à 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 »13.1.8.11. Se passer des sous-requêtes avec les premières versions de MySQL pour des exemples d'illustration.

Le serveur MySQL ne supporte pas encore l'extension Oracle SQL : SELECT ... INTO TABLE .... À la place, le serveur MySQL supporte la syntaxe ANSI SQL INSERT INTO ... SELECT ..., qui revient au même. Voir Section 13.1.4.1, « Syntaxe de INSERT ... SELECT »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. Voir Section 19.2.9.3, « Syntaxe de SELECT ... INTO »19.2.9.3. Syntaxe de SELECT ... INTO.

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. Voir Chapitre 14, Moteurs de tables MySQL et types de tableChapitre 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 à 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 soient levés, sans que le client n'attende cette levée de verrou. Voir Section 13.1.4.2, « Syntaxe de INSERT DELAYED »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és.

  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 :

   

  Sélectionnez

  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 identifiants 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(). Voir Section 12.8.3, « Fonctions d'informations »12.8.3. Fonctions d'informations. Voir Section 24.2.3.33, « mysql_insert_id() »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 :

   

  Sélectionnez

  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 :

   

  Sélectionnez

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

Les procédures stockées sont implémentées en version 5.0. Voir Chapitre 19, Procédures stockées et fonctionsChapitre 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.

En MySQL version 3.23.44 et plus récentes, les tables InnoDB supportent les vérifications d'intégrité référentielles. Voir Chapitre 15, Le moteur de tables InnoDBChapitre 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és é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 inutile l'application de ces vérifications du côté 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 simplifient 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 base, 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. Voir Section 7.3.2, « Problème de verrouillage de tables »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 côté 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 multitables pour effacer les lignes dans plusieurs tables en une seule commande. Voir Section 13.1.1, « Syntaxe de DELETE »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 peut 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. Voir Section 15.7.4, « Contraintes de clés étrangères FOREIGN KEY »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;

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

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

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. Voir Section 5.5, « Règles de sécurité et droits d'accès au serveur MySQL »5.5. Règles de sécurité et droits d'accès au serveur MySQL.

De nombreuses bases ne 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.

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 */. Voir Section 9.5, « Syntaxe des commentaires »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 '--' peuvt 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

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 transactionnel, 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. Voir Section 24.2.3.31, « mysql_info() »24.2.3.31. mysql_info(). Voir Section 13.5.3.19, « SHOW WARNINGS | ERRORS »13.5.3.19. SHOW WARNINGS | ERRORS.

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

Pour être capables 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 grande 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. Voir Section 2.4.2, « Options habituelles de configure »2.4.2. Options habituelles de configure. Cela fait que les commandes INSERT génèreront une erreur à moins que vous ne spécifiiez 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 pourrons pas annuler la modification, car la table ne le supporte peut-être pas. L'alternative qui consiste à s'arrêter n'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 de rien n'était arrivé. En MySQL 5.0, nous envisageons d'améliorer cela en fournissant des alertes de conversions automatiques, 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.

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 champ ENUM, la colonne prendra la valeur réservée 0, qui sera représentée par une chaîne vide, en mode chaîne. Voir Section 11.4.4, « Le type ENUM »11.4.4. Le type ENUM.

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

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 bogues bien pires. 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 elles, alors qu'un autre thread essaie 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 la valeur maximale de la colonne. Corrigé en 4.0.11.

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

Voici la liste des bogues/erreurs qui ne sont pas corrigés en MySQL 4.0, car cette correction prendrait trop de manipulations, qui risqueraient d'introduire encore d'autres bogues. Les bogues sont aussi classés comme « non fatals » ou « supportables ».

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

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 potentielle de bogues bien pires. Ces bogues sont classés comme « non fatals » ou « tolérables ».

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

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

   

  Sélectionnez

  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édant 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 cours 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ée 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 faits 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ée 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, pour le maître utiliser InnoDB et pour 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 bases, 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éterministes, pour s'assurer 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. Voir Section 8.5, « mysqlbinlog, Exécuter des requêtes dans le log binaire »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 :

   

  Sélectionnez

  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 tables 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 ;

• à cause de la méthode de stockage des tables de définition 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. Voir Section 2.4.5, « Notes relatives aux MIT-pthreads »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îne, hormis les BLOB et TEXT, voient automatiquement leurs caractères blancs finals 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 faites référence à une colonne modifiée, vous obtiendrez sa valeur modifiée, plutôt que sa valeur originale. Par exemple :

   

  Sélectionnez

  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 :

   

  Sélectionnez

  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 :

   

  Sélectionnez

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

  et

   

  Sélectionnez

  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 colonne 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 à une 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 :

   

  Sélectionnez

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

  Un palliatif est :

   

  Sélectionnez

  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. Voir Section 2.4, « Installation de MySQL avec une distribution source »2.4. Installation de MySQL avec une distribution source. Voir Annexe D, Port vers d'autres systèmesAnnexe D. Port vers d'autres systèmes.