Dans le passé, il n'y avait que utf8; dans le futur, maintenant utf8mb4 sera le jeu de caractères par défaut.utf8mb4 est le jeu de caractères par défaut.
Dans le passé, _general_ci était le classement par défaut ; puis _unicode_ci (Unicode 4.0) était mieux, alors _unicode_520_ci (Unicode 5.20). À l'avenir (MySQL 8.0), la valeur par défaut sera _0900_ci_ai (Unicode 9.0).
Pendant ce temps, la route est pleine de nids-de-poule générés par les erreurs passées de MySQL. Et les concepteurs de WP conduisent dans un gros réservoir qui ne remarque pas les nids-de-poule.
MySQL 5.6 était un gros nid de poule qui a englouti de nombreux utilisateurs WP en raison d'une limite de 767 sur les index avec les index WP sur le trop long VARCHAR(255) et la possibilité d'utiliser utf8mb4 . Vous l'avez bien dépassé en ayant 5.7.17. (Votre future migration vers la 8.0 sera moins cahoteuse.)
Autrement dit, les bases de données/tables/colonnes nouvellement créées sur 5.7.7+ ne devraient pas rencontrer le problème 767, mais les éléments migrés à partir d'anciennes versions (5.5.3+) peuvent avoir des problèmes, surtout si quelque chose vous amène à passer à utf8mb4.
Que faire? Je vais probablement manquer d'espace pour essayer d'épeler toutes les options. Fournissez donc l'historique des données, le chemin de mise à niveau (le cas échéant), les paramètres actuels, le ROW_FORMAT des tables, le CHARACTER SET et COLLATION des colonnes, la sortie de SHOW VARIABLES LIKE 'char%';
Où devriez-vous être ? Pour 5.7.7+, utf8mb4 et utf8mb4_unicode_520_ci partout où c'est pratique. Ce jeu de caractères vous donne Emoji et tout le chinois (utf8 ne le fait pas). Cette collation est la meilleure disponible, bien que vous ayez peut-être du mal à remarquer où cela compte.
Remarque :la première partie du nom du classement est le seul jeu de caractères avec lequel il fonctionne. C'est utf8_unicode_ci ne fonctionne pas avec utf8mb4 .
