Chapitre 1 Informations générales

Amélioration des performances

Serveur MySQL embarqué

Le moteur InnoDB en standard

Nouvelles fonctionnalités

Respect des standards, portabilité et migration

Internationalisation

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.

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

Accélération

Nouvelle fonctionnalité

Compatibilité avec les standards, portabilité et migration

Internationalisation

Améliorations d'ergonomie

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.

<mysql-france-subscribe@yahoogroups.com>

Une liste de diffusion fran¸aise

<list@tinc.net>

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

<mysql-de-request@lists.4t2.com>

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

<mysql-br-request@listas.linkway.com.br>

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

<mysql-alta@elistas.net>

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

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.

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 à <licensing@mysql.com> 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 ».

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 :

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 :

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;

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.

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.

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.

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.

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.

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.

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

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 :

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 :

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.

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

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 :

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.