В миналото имаше само utf8; в бъдеще, сега utf8mb4 ще бъде наборът от символи по подразбиране.utf8mb4 е наборът от символи по подразбиране.
В миналото _general_ci беше съпоставянето по подразбиране; след това _unicode_ci (Unicode 4.0) беше по-добър, след това _unicode_520_ci (Юникод 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 от таблиците, CHARACTER SET и COLLATION от колоните, изходът на SHOW VARIABLES LIKE 'char%';
Къде трябва да бъдеш? За 5.7.7+, utf8mb4 и utf8mb4_unicode_520_ci където е практично. Този набор от знаци ви дава емоджи и целия китайски (utf8 не). Това съпоставяне е най-доброто налично, въпреки че може да ви е трудно да забележите къде има значение.
Забележка:първата част от името на съпоставянето е единственият набор от знаци, с който работи. Това е utf8_unicode_ci не работи с utf8mb4 .
