En el pasado, solo existía utf8; en el futuro, ahora utf8mb4 será el conjunto de caracteres predeterminado.utf8mb4 es el conjunto de caracteres predeterminado.
En el pasado, _general_ci fue la intercalación predeterminada; entonces _unicode_ci (Unicode 4.0) era mejor, entonces _unicode_520_ci (Unicode 5.20). En el futuro (MySQL 8.0), el valor predeterminado será _0900_ci_ai (Unicode 9.0).
Mientras tanto, el camino está lleno de baches generados por los errores del pasado de MySQL. Y los diseñadores de WP conducen un gran tanque que no nota los baches.
MySQL 5.6 fue un gran bache que absorbió a muchos usuarios de WP debido a un límite de 767 en los índices junto con los índices de WP en el VARCHAR(255) demasiado largo y la posibilidad de usar utf8mb4 . Ya lo superaste al tener 5.7.17. (Su futuro paso a 8.0 será menos accidentado).
Es decir, las bases de datos/tablas/columnas recién creadas en 5.7.7+ no deberían experimentar el problema 767, pero las cosas migradas desde versiones anteriores (5.5.3+) pueden tener problemas, especialmente si algo hace que cambie a utf8mb4.
¿Qué hacer? Probablemente me quede sin espacio tratando de explicar todas las opciones. Proporcione el historial de los datos, la ruta de actualización (si corresponde), la configuración actual, el ROW_FORMAT de las tablas, el CHARACTER SET y COLLATION de las columnas, la salida de SHOW VARIABLES LIKE 'char%';
¿Dónde deberías estar? Para 5.7.7+, utf8mb4 y utf8mb4_unicode_520_ci donde sea práctico. Ese conjunto de caracteres te da Emoji y todo chino (utf8 no lo hace). Esa colación es la mejor disponible, aunque es posible que le cueste darse cuenta de dónde importa.
Nota:la primera parte del nombre de colación es el único conjunto de caracteres con el que funciona. Eso es utf8_unicode_ci no funciona con utf8mb4 .
