Il y a trop de tables. Seuls les pseudonymes et les commentaires sont définis sur utf8mb4.
config, tag, router, etc. n'utilisez pas du tout utf8mb4
Ce mélange d'utf8 utf8mb4
aura-t-il un impact sur la recherche, indexation et enregistrements de journaux ?
Est-ce plus rapide que l'utf8mb4 pur ? Est-ce stable ?
Avez-vous besoin de modifier une configuration dans la configuration mysqld et d'optimiser utf8mb4
Si le code PHP DB_CHARSET définit utf8mb4, cela affectera-t-il les données uft8 ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Il n'y a pas beaucoup d'avantages
.Parce que utf8mb4 n'utilise que 4 octets pour stocker les caractères spéciaux tels que les emoji
Le reste du temps, les performances sont les mêmes que le jeu de caractères utf8 de MySQL est toujours de 3 octets
(Parce que l'implémentation de la longueur maximale d'un seul caractère dans le jeu de caractères MySQL utf8 est erronée, le jeu de caractères utf8mb4 est sorti. En fait, cet utf8mb4 est l'utf8 standard)
Bien sûr, vous devez éviter d'utiliser char et utiliser varchar à la place, car le type de colonne char de mysql est sous utf8mb4. Afin de garantir que toutes les données sont stockées, char occupera le nombre d'octets * 4 caractères (la colonne char. Le type de mysql utf8 occupera le nombre d'octets (nombre de caractères * 3) pour assurer une allocation d'espace suffisante. Par conséquent, il est recommandé d'utiliser un varchar de longueur variable pour économiser de l'espace. L'espace de stockage consommé par la longueur variable est : le nombre d'octets. requis pour le stockage réel + 1 ou La longueur exprimée en 2 octets.
De plus, pour les colonnes de caractères anglais purs, vous pouvez également envisager des colonnes varbinary (binaire de longueur variable) et binaire (adaptées aux caractères anglais de longueur fixe, tels que les hachages de mots de passe). Les performances sont légèrement meilleures que varchar, car cela stocke). données binaires