Mysql migration utf8->utf8mb4

WRInaute passionné
Bonjour,
Pour avoir accès à l'enregistrement des émoticons (et autres) saisis depuis des smartphone dans ma base de données Mysql (version 5.7.x), j'ai besoin de migrer l'encodage de ma base de UTF8 en UTF8MB4

après recherche, il semble qu'il n'y ait pas de problème majeur et que la compatibilté ascendante est assurée.

Mais yany trouvé très peu de docuementation là dessus, je souhaiterai avoir votre retour d'expérience.

Etes vous déjà en UTF8mb4 ? la migration s'est elle bien passée ?

d'avance merci
 
WRInaute passionné
ok merci @rick38

j'ai cru comprendre que l'on ne pouvait pas migrer une seule colonne ou table en ut8mb4 , bien que l'action (dans phpmyadmin par exemple) soit possible

sais tu pourquoi ?
 
WRInaute passionné
ok dernière question

utilise tu utf8mb4_general_ci OU utf8mb4_unicode_ci ?
et quelle est la différence stp ?
 
WRInaute impliqué
Personnellement, utf8mb4_general_ci.

Les différences :
En français : https://askcodez.com/difference-ent...et-utf8mb4_general_ci-dans-mariadb-mysql.html

Complément, en anglais : https://stackoverflow.com/questions...e-between-utf8-general-ci-and-utf8-unicode-ci

À vrai dire, je m'en fous un peu : la quasi totalité de mes champs utf8mb4 concernent du contenu d'utilisateurs sur lesquels je n'utilise aucune fonction de tri : je me contente de le stocker et de l'afficher, c'est tout.
Le tri se fait généralement par rapport à d'autres champs (une date, le plus souvent, comme par exemple pour cette page : les messages sont classés par date et je ne vois pas de cas concret où on pourrait vouloir classer les messages par ordre alphabétique).

Il peut éventuellement arriver que je fasse un tri par rapport à un champ titre stocké en utf8mb4 (petite messagerie interne, par exemple, si l'utilisateur choisir de trier les messages par ordre alphabétique des sujets), mais franchement, les différences éventuelles sur des cas rares ne m'empêchent pas de dormir et ne risquent pas de bouleverser mes utilisateurs (s'ils se produisaient).

Mais si le tri est important pour toi, utilise utf8mb4_unicode_ci... ou une des options plus récentes qui corrigent encore quelques cas rares. Auquel cas, il faudrait passer à MySQL 8 qui a encore corrigé quelques cas dans une nouvelle collation, apparemment (et qui t'apportera de meilleures perfs, soit dit en passant).
 
WRInaute passionné
Ok merci,

j'ai juste à faire quelques vérifications et etsts sur les champs CHAR, VARCHAR et TEXT qui semblent être les seuls touchés dans cette conversion par rapport à la longueur maximale de ces champs : on passe d 3 octets à 4 octets donc c normal.
 
WRInaute impliqué
Attend... convertir des champs CHAR ? Comment se fait-il que tu aies ce genre de cas ?
Tu stockes quoi dans ces champs ?
 
WRInaute passionné
question concernant PHP toutes les fonctions tournant autour de UTF8, telles que utf8_encode ou UTF8_decode, ...

j'imagine qu'elles utilisent UTF8 sur 4 octets ?
 
WRInaute passionné
Petit retour d'expérience suite à migration utf8(mb3) vers utf8mb4 avec MySql 5.7.x
Attention à la longueur des clefs VARCHAR : la longueur d'un index avec VARCHAR est limitée à 1000 octets
j'avais l'habitude de coder mes adresse mails avec des VARCHAR(255) sur 3 octets (utf8mb3) cela fait bien moins de 1000 octets (3 x 255 = 765)
mais avec utf8mb4 ça dépasse : 4 octets x 255 = 1020

il faut donc coder sur 250 caractères maximum les VARCHAR destinés à un index (unique, etc...) pour les autres (non indexés) auxcun problème
 
Discussions similaires
Haut