E Erreurs connues et manques de MySQL

• Impossible de créer un autre dossier lors de l'utilisation de MIT-pthreads. Etant donné que ceci requiert une modification de MIT-pthreads, nous ne pouvons pas corriger ce problème.
• Les valeurs de type BLOB ne peuvent pas être utilisées de manière ``sûre'' dans les clauses GROUP BY, ORDER BY ou DISTINCT. Seuls, les max_sort_length premiers octets (par défaut 1024) sont utilisés dans les comparaisons entre BLOB. Cela peut être changé avec l'option -O max_sort_length de mysqld. Une solution pour contourner le problème est d'utiliser une sous chaîne : SELECT DISTINCT LEFT(blob,2048) FROM nom_table.
• Les calculs sont fait avec BIGINT ou DOUBLE (les deux font 64 bits de long). La précision de calcul dépend de la fonction. La régle générale est que les fonctions de bits sont fait en précision BIGINT, IF et ELT() avec une précision BIGINT ou DOUBLE, et le reste est fait en précision DOUBLE. Il vaut mieux éviter d'utiliser les valeurs non signées, supérieures à 63 bits(9223372036854775807) pour tout ce qui n'est pas champs de bits.
• Avant MySQL 3.23 tous tous les types numériques étaient traités comme des champs à virgule fixées. Cela signifie que vous deviez préciser le nombre de décimales d'un nombre à virgule flottante. Les résultats étaient retournés avec un nombre corrects de décimale.
• Toutes les colonnes, hormis BLOB et TEXT, sont automatiquement débarassées de leurs espaces de fin de chaînes. Pour les types CHAR c'est bon, et peut même être vu comme une fonctionnalité, d'après la norme ANSI SQL92. Le bug est que MySQL traite les colonnes VARCHAR de la même façon.
• MySQL limite à 255 colonnes de type ENUM et SET dans une seule table.
• Avant MySQL 3.23.2, une commande UPDATE qui modifiait une clé avec une clause WHERE sur la même clé pouvait échouer car la clé était utilisée pour rechercher les lignes, et la même ligne risque d'avoir été trouvée plusieurs fois.

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

  Pour contourner le problème, on pourvait utiliser la requête suivante :

  mysql> UPDATE nom_table SET KEY=KEY+1 WHERE KEY+0 > 100;
  

  Cela va fonctionner, car MySQL ne va pas utiliser d'index dans les expressions qui sont dans la clause WHERE.
• safe_mysqld redirige tous les messages de mysqld vers l'historique mysqld. Le problème est que si vous exécutez la commande mysqladmin refresh pour fermer et réouvrir l'historique, stdout et stderr continue de pointer sur l'ancien fichier d'historique. Si vous utilisez --log extensivement, il vaut mieux éditer le fichier safe_mysqld et y mettre `'hostname'.err' au lieu de `'hostname'.log' pour que vous puissiez facilement récupérer l'espace de l'ancien fichier d'historique, en effacant l'ancient, et 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 allez utiliser la valeur modifiée, au lieu d'utiliser la valeur originale. Par exemple :

  mysql> UPDATE nom_table SET KEY=KEY+1,KEY=KEY+1
  

  va mettre dans KEY la valeur 2 au lieu de 1.

Pour les bugs spécifiques à chaque plate forme, reportez vous à la section sur la compilation et le portage.