10.1.11. Обновление от До Текущей Поддержки Unicode

Этот раздел описывает проблемы, имеющие отношение к поддержке Unicode, к которой можно быть обращенным, обновляя до MySQL 5.6 от более старого выпуска MySQL. Это также обеспечивает направляющие линии для того, чтобы они понизили от MySQL 5.6 до более старого выпуска.

В большинстве отношений, обновляя до MySQL 5.6 должен представить немного проблем относительно использования Unicode, хотя есть некоторые потенциальные области несовместимости. Они - основные проблемные области:

Для символьных типов данных переменной длины (VARCHAR и TEXT типы), максимальная длина в символах меньше для utf8mb4 столбцы чем для utf8 столбцы.
Для всех символьных типов данных (CHAR, VARCHAR, и TEXT типы), максимальное количество символов, которые могут быть индексированы, меньше для utf8mb4 столбцы чем для utf8 столбцы.

Следовательно, если Вы хотите обновить таблицы от utf8 к utf8mb4 чтобы использовать в своих интересах дополнительно-символьную поддержку, может быть необходимо измениться на некоторый столбец или индексировать определения.

Таблицы могут быть преобразованы из utf8 к utf8mb4 при использовании ALTER TABLE. Предположите, что таблица была первоначально определена следующим образом:

CREATE TABLE t1 (  col1 CHAR(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,  col2 CHAR(10) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL) CHARACTER SET utf8;

Следующий оператор преобразовывает t1 использовать utf8mb4:

ALTER TABLE t1  DEFAULT CHARACTER SET utf8mb4,  MODIFY col1 CHAR(10)    CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,  MODIFY col2 CHAR(10)    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;

С точки зрения табличного контента, преобразования из utf8 к utf8mb4 подарки никакие проблемы:

Для символа BMP, utf8 и utf8mb4 имейте идентичные характеристики хранения: те же самые кодовые обозначения, то же самое кодирование, та же самая длина.
Для дополнительного символа, utf8 не может сохранить символ вообще, в то время как utf8mb4 требует, чтобы четыре байта сохранили это. С тех пор utf8 не может сохранить символ вообще, у Вас нет никаких дополнительных символов в utf8 столбцы и Вы не должны волноваться о преобразовании символов или потере данных, обновляя utf8 данные от более старых версий MySQL.

С точки зрения структуры таблицы, выгоды, преобразовывая из utf8 к utf8mb4 это максимальная длина столбца, или индексируйте ключ, неизменно с точки зрения байтов. Поэтому, это меньше с точки зрения символов, потому что максимальная длина символа составляет четыре байта вместо три. Для CHAR, VARCHAR, и TEXT типы данных, наблюдайте за этими вещами, преобразовывая Ваши таблицы MySQL:

Проверьте все определения utf8 столбцы и удостоверяются, что не будут превышать максимальную длину для механизма хранения.
Проверьте, что все индексирует на utf8 столбцы и удостоверяются, что не будут превышать максимальную длину для механизма хранения. Иногда максимум может измениться из-за улучшений механизма хранения.

Если предыдущие условия применяются, следует или уменьшить определенную длину столбцов или индексируете, или продолжайте использовать utf8 вместо utf8mb4.

Вот некоторые примеры, где структурные изменения могут быть необходимы:

A TINYTEXT столбец может содержать до 255 байтов, таким образом, он может содержать до 85 3 байтов или 63 4-байтовых символа. Предположите, что у Вас есть a TINYTEXT столбец, который использует utf8 но должен быть в состоянии содержать больше чем 63 символа. Невозможно преобразовать это в utf8mb4 если Вы также не изменяете тип данных на более длинный тип такой как TEXT.

Точно так же очень длинное VARCHAR столбец, возможно, должен быть изменен на один из дольше TEXT типы, если Вы хотите преобразовать это из utf8 к utf8mb4.
InnoDB имеет максимум, индексируют длину 767 байтов, таким образом, для utf8 или utf8mb4 столбцы, можно индексировать максимум 255 или 191 символа, соответственно. Если Вы в настоящий момент имеете utf8 столбцы с индексируют дольше чем 191 символ, Вы должны будете индексировать меньшее число символов. В InnoDB таблица, они, столбец и индексирует определения, являются законными:
```
col1 VARCHAR(500) CHARACTER SET utf8, INDEX (col1(255))
```
Использовать utf8mb4 вместо этого, индексирование должно быть меньшим:
```
col1 VARCHAR(500) CHARACTER SET utf8mb4, INDEX (col1(191))
```

Предыдущие типы изменений, наиболее вероятно, будут требоваться, только если у Вас есть очень длинные столбцы, или индексирует. Иначе, следует быть в состоянии преобразовать свои таблицы из utf8 к utf8mb4 без проблем. Можно сделать это при использовании ALTER TABLE как описано ранее в этом разделе после обновления на месте до 5.6.

Следующие элементы суммируют другие потенциальные области несовместимости:

Производительность 4-байтового UTF-8 (utf8mb4) медленнее чем для 3-байтового UTF-8 (utf8). Если Вы не хотите подвергаться этому штрафу, продолжайте использовать utf8.
SET NAMES 'utf8mb4' использование причин 4-байтового набора символов для наборов символов соединения. Пока символы 4 байтов номера отправляются от сервера, не должно быть никаких проблем. Иначе, у приложений, которые ожидают получать максимум трех байтов за символ, могут быть проблемы. Наоборот, приложения, которые ожидают отправлять 4-байтовые символы, должны гарантировать, что сервер понимает их.
Приложения не могут передаться utf16, utf16le, или utf32 символьные данные к более старому серверу, который не понимает их.
Для репликации, если наборы символов, которые поддерживают дополнительные символы, собираются использоваться на ведущем устройстве, все ведомые устройства должны понять их также. Если Вы пытаетесь тиражироваться от ведущего устройства MySQL 5.6 к более старому ведомому устройству, utf8 данные будут замечены как utf8 ведомым устройством и должен тиражироваться правильно. Но невозможно передаться utf8mb4, utf16, utf16le, или utf32 данные.

Кроме того, имейте в виду общий принцип, что, если у таблицы есть различные определения на ведущем устройстве и ведомом устройстве, это может привести к неожиданным результатам. Например, различия в ограничениях на индексируют длину ключа, делает опасным, чтобы использовать utf8 на ведущем устройстве и utf8mb4 на ведомом устройстве.

Если Вы обновили до MySQL 5.6, и затем решаете понизить назад к более старому выпуску, эти соображения применяются:

ucs2 и utf8 данные не должны представить проблемы.
Любые определения, которые относятся к utf8mb4, utf16, utf16le, или utf32 наборы символов не будут распознаны более старым сервером.
Для объектных определений, которые относятся к utf8mb4 набор символов, можно вывести их с mysqldump в MySQL 5.6, отредактировать файл дампа, чтобы изменить экземпляры utf8mb4 к utf8, и перезагрузите файл в более старом сервере, пока есть символы 4 байтов номера в данных. Более старый сервер будет видеть utf8 в дампе файл возражает определениям и создает новые объекты, которые используют (3 байта) utf8 набор символов.