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