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