Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/07017.jsonl.gz/264

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