Vérifiez la liste des modifications de cette section, vous voir si elles ont un impact sur vos applications.

Lisez la liste des nouveautés de la version 4.1 pour identifier les nouvelles fonctionnalités significatives pour vos projets. See Section C.2, « Changements de la version 4.1.x (Alpha) ».

Si vous faites fonctionner MySQL sur Windows, voyez Section 2.2.11, « Mettre à jour MySQL sous Windows ».

Après mise à jour du serveur, mettez à jour les tables de droits, pour accepter des colonnes Password plus grande. La procédure utilise le script mysql_fix_privilege_tables et est décrite dans la section Section 2.6.7, « Mise à jour des tables de droits ». Les implications du changement de gestion du mot de passe est décrit plus loin dans cette section. Si vous ne le faîtes pas, MySQL ne pourra pas utiliser le protocole sécuritaire pour l'identification.

Si vous utilisez la réplication, voyez la section Section 6.6, « Changer de version de réplication » pour mettre à jour votre installation.

Le moteur de table Berkeley DB table est passé en version DB 4.1 (depuis la 3.2), et il dispose d'un nouveau format de log. Si vous devez revenir en version 4.0, vous devrez utiliser mysqldump pour exporter vos tables BDB au format texte, et effacer tout les fichiers log.XXXXXXXXXX avant de redémarrer le serveur MySQL 4.0 et de réimporter les données.

Le support des jeux de caractères a été amélioré. si vous avez des tables qui contiennent des données représentées dans un jeu de caractères que MySQL 4.1 supporte directement, vous pouvez convertir ces colonnes vers le bon jeu de caractères avec les instructions du chapitre Section 10.10.2, « Conversion de colonnes version 4.0 en version 4.1 ».

Si vous utilisez un vieux module DBD-mysql (Msql-MySQL-modules) vous devez mettre à jour le module DBD-mysql. Tout ce qui est plus récent que DBD-mysql 2.xx doit convenir.

Si vous ne mettez pas à jour, certaines commandes telles que DBI->do() ne rapporteront pas correctement les erreurs.

L'option --defaults-file=option-file-name vous donnera une erreur si le fichier d'options n'existe pas.

Toutes les colonnes et tables ont désormais un jeu de caractères, qui apparaît dans le résultat de la commande SHOW CREATE TABLE et mysqldump. See Chapitre 10, Jeux de caractères et Unicode. (MySQL 4.0.6 et plus récent peuvent lire les nouveaux fichiers de dump, mais pas les plus anciennes versions de MySQL). Cela ne doit pas affecter les applications qui n'utilisent qu'un seul jeu de caractères.

Le format de définition de table du fichier .frm a légèrement changé en version 4.1. Les versions de MySQL 4.0 à partir de la 4.0.11 peuvent lire le nouveau format .frm directement, mais les versions plus anciennes ne le peuvent pas. Si vous devez déplacer des tables de la version 4.1 vers une version 4.0.11, passez plutôt par mysqldump. See Section 8.8, « mysqldump, sauvegarde des structures de tables et les données ».

Note importante : si vous mettez à jour en version InnoDB-4.1.1 ou plus récent, il sera difficile de revenir à une version plus ancienne, 4.0 or 4.1.0! Ceci est dû aux versions de InnoDB qui ne reconnaissent pas les espaces de table multiples.

Si vous utilisez plusieurs serveurs sur la même machine Windows, vous devriez utiliser l'option --shared_memory_base_name avec des valeurs différentes sur toutes les machines.

L'interface des fonctions UDF agrégeantes a un peu changé. Vous devez commencer par déclarer une fonction xxx_clear() pour chaque fonction agrégeante XXX().

mysqldump dispose des options --opt et --quote-names, qui sont activées par défaut. Vous pouvez les désactiver avec --skip-opt et --skip-quote-names.

La comparaison de chaînes fonctionne maintenant conformément au standard SQL : au lieu de supprimer les espaces de fin de chaîne avant la comparaison, nous complétons les chaînes courte avec des espaces. Le problème est que maintenant, 'a' > 'a\t', ce qui n'était pas le cas avant. Si vous avez des tables avec des colonnes CHAR ou VARCHAR dont le dernier caractères peut être de code ASCII(32) ou plus petit, vous devez utiliser la commande REPAIR TABLE ou myisamchk.

Lorsque vous utilisez des commandes DELETE multi-tables, vous devez utiliser les alias de tables que vous voulez effacer, et non pas le véritable nom de la table. Par exemple, au lieu de :

DELETE test FROM test AS t1, test2 WHERE ...

faîtes :

DELETE t1 FROM test AS t1, test2 WHERE ...

TIMESTAMP est maintenant retourné comme une chaîne, au format 'YYYY-MM-DD HH:MM:SS'. L'option --new peut être utilisée depuis la version 4.0.12, pour que le serveur adopte le comportement de la version 4.1 pour ce point. Si vous voulez recevoir la version entière de la valeur, comme en version 4.0, il suffit d'ajouter +0 à chaque colonne TIMESTAMP :

mysql> SELECT ts_col + 0 FROM tbl_name;

La largeur d'affichage des colonnes TIMESTAMP ne sont plus supportées. Par exemple, si vous déclarez une colonne de type TIMESTAMP(10), le nombre (10) est ignoré.

Ces changements sont nécessaires pour respecter les standards SQL. Dans une future version, une autre modification aura lieu, mais restera compatible avec celle-ci : la taille de la valeur TIMESTAMP indiquera le nombre de chiffres voulu pour les fractions de secondes.

Les valeurs binaires, comme 0xFFDF, sont maintenant supposées être des chaînes et non pas des nombres. Cela corrige des problèmes avec les jeux de caractères, où il est plus pratique d'insérer une chaîne comme une chaîne binaire. Avec cette modification, vous devez utiliser la fonction CAST() si vous voulez comparer des valeurs binaires avec les entiers :

mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER);
        -> 0

Si vous n'utilisez pas CAST(), une comparaison lexicale de la chaîne aura lieu  :

mysql> SELECT 0xFEFF < 0xFF;
        -> 1

Utiliser des chaînes binaires dans un contexte numérique, ou bien comparer des valeurs avec les opérateurs comme = devrait fonctionner comme auparavant. L'option --new peut être utilisée à partir de la version 4.0.13 pour que le serveur 4.0 se comporte comme le serveur 4.1.

Les fonctions qui retournent des DATE, DATETIME, ou TIME sont désormais traitées lors de leur arrivée sur le client. Par exemple, en MySQL 4.1, vous obtenez le résultat suivant :

mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01 00:00:00'

En MySQL 4.0, le résultat est différent :

mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01'

Les valeurs DEFAULT ne peuvent plus être spécifiées pour les colonnes de type AUTO_INCREMENT. En 4.0, la clause DEFAULT est ignorée silencieusement. En 4.1, une erreur survient.

LIMIT n'accepte plus les arguments négatifs. Utilisez 18446744073709551615 au lieu de -1.

SERIALIZE n'est plus une option valide pour la variable sql_mode. Il faut utiliser la commande SET TRANSACTION ISOLATION LEVEL SERIALIZABLE à la place. SERIALIZE n'est plus valide comme option de --sql-mode pour mysqld, non plus. Utilisez --transaction-isolation=SERIALIZABLE.

Certaines fonctions C telles que mysql_real_query() retournent maintenant 1 en cas d'erreur, et non plus -1. Vous aurez peut être à changer certaines anciennes applications comme ceci :

if (mysql_real_query(mysql_object, query, query_length) == -1)
{
  printf("Erreur");
}

Modifiez le test de comparaison à 0 :

if (mysql_real_query(mysql_object, query, query_length) != 0)
{
  printf("Erreur");
}

Ne passez pas en version 4.1. Aucun comportement ne changera, mais vous ne pourrez pas utiliser les nouvelles fonctionnalités du protocole de la version 4.1. MySQL a amélioré le protocole client/serveur de la version 4.1, en ajoutant les commandes préparées et le support des jeux de caractères. See Section 24.2.4, « Fonctions C de commandes préparées ».

Passez en version 4.1, utilisez le script mysql_fix_privilege_tables pour agrandir la colonne Password de la table user pour qu'elle puisse contenir les nouveaux hashs de mots de passe. Mais lancez le serveur avec l'option --old-passwords pour que les clients pre-4.1 puissent continuer d'utiliser leurs anciens comptes. Finalement, lorsque tous les clients seront passés en version 4.1, vous pourrez cesser d'utiliser l'option --old-passwords. Vous pouvez aussi changer les mots de passe de vos comptes MySQL pour adopter le nouveau format.

Passez en version 4.1 et utilisez le script mysql_fix_privilege_tables pour aggrandir la colonne Password de la table user. Si vous savez que tous les clients sont passés en version 4.1, n'utilisez pas l'option --old-passwords. Au lieu de cela, changez les mots de passe de tous les comptes, pour qu'ils adoptent le nouveau format. Une installation 100% 4.1 est la plus sûre.