Почему для таблицы CHARSET установлено значение utf8mb4, а для COLLATION - utf8mb4_unicode_520_ci

Раньше было только utf8; в будущем utf8mb4 будет символьным набором по умолчанию.

Раньше _general_ci была сортировкой по умолчанию; то _unicode_ci (Unicode 4.0) был лучше, затем _unicode_520_ci (Unicode 5.20). В будущем (MySQL 8.0) по умолчанию будет _0900_ci_ai (Unicode 9.0).

Между тем, дорога полна выбоин, порожденных ошибками MySQL. И дизайнеры WP ездят в большом танке, который не замечает выбоины.

MySQL 5.6 был большой выбоиной, которая поглотила многих пользователей WP из-за ограничения 767 индексов вместе с индексами WP на слишком длинном VARCHAR(255) и возможностью использования utf8mb4. Вы прошли мимо него, имея 5.7.17. (Ваш будущий переход на 8.0 будет менее ухабистым.)

То есть, новые созданные базы данных/таблицы/столбцы на 5.7. 7+ не должны испытывать проблему 767, но могут быть проблемы, перенесенные из более старых версий (5.5. 3+), особенно если что-то заставляет вас перейти на utf8mb4.

Что делать? Я, вероятно, исчерпаю пространство, пытаясь рассказать обо всех вариантах. Таким образом, ROW_FORMAT историю данных, путь обновления (если есть), текущие настройки, ROW_FORMAT таблиц, CHARACTER SET и COLLATION столбцов, выход SHOW VARIABLES LIKE 'char%';

Где вы должны быть? Для 5.7. 7+, utf8mb4 и utf8mb4_unicode_520_ci где это практически целесообразно. Эта кодировка дает вам Emoji и все китайцы (utf8 не делает). Это сопоставление является самым доступным, хотя вам может быть трудно заметить, где это важно.

Примечание: первая часть имени сортировки - это единственный набор символов, с которым он работает. То есть utf8_unicode_ci не работает с utf8mb4.