MySQL VARCHAR длины и UTF-8

в MySQL, если я создам новый VARCHAR(32) поле в таблице UTF-8 означает ли это, что я могу хранить 32 байта данных в этом поле или 32 символа (многобайтовые)?

5 ответов


этот ответ появился в верхней части результатов поиска Google, но не исправить так:

путаница, вероятно, связана с различными версиями mysql, которые тестируются.

  • версия 4 подсчитывает байт
  • версия 5 подсчитывает символы

http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html

MySQL интерпретирует спецификации длины в определениях столбцов символов в единицы характера. (До MySQL 4.1 длины столбцов интерпретировались в байтах.) Это относится к типам CHAR, VARCHAR и TEXT.

интересно (я не думал об этом) максимальная длина столбца varchar зависит от utf8 следующим образом:

эффективная максимальная длина VARCHAR в MySQL 5.0.3 и позже зависит от максимального размера строки (65,535 байта, который разделяется между всеми столбцами) и используемого набора символов. Например, utf8 символы могут требовать до трех байтов на символ, поэтому столбец VARCHAR, использующий набор символов utf8, может быть объявлен как максимум 21,844 символа.


Это позволит вам хранить 32 многобайтовых символов

чтобы сэкономить место с UTF-8, используйте ВАРЧАР вместо Чара. Иначе, MySQL должен зарезервировать три байта для каждый символ в наборе символов CHAR столбец utf8, потому что это максимально возможная длина. Например, MySQL должен зарезервировать 30 байт для Char (10) набор символов utf8 столбец.

http://dev.mysql.com/doc/refman/5.0/en/charset-unicode.html


32 multibytes данные varchar(32) С сортировки utf8_unicode_ci, Я только что тестировал с XAMPP.

1234567890123456789012345678901234567890

обрезались до:

12345678901234567890123456789012

имейте в виду, что это не обычные символы ASCII.


лучше использовать "char" для таблиц обновления с высокой частотой, потому что общая длина данных строки будет фиксированной и быстрой. Столбцы Varchar делают динамическими размеры данных строк. Это плохо для MyISAM, но я не знаю о InnoDB и других. Например, если у вас очень узкий столбец "тип", возможно, лучше использовать char(2) с кодировкой latin1, чтобы претендовать только на минимальное пространство.


если вы подключаетесь к базе данных, используя кодировку latin1 (например, с PHP), чтобы сохранить строку PHP UTF8 в столбце MySQL UTF8, у вас будет двойная кодировка UTF8.

если строка UTF8 $s имеет длину 32 символа, но 64 байта, а столбец VARCHAR(32) UTF8, двойная кодировка преобразует строку $s до строки UTF8 длиной 64 символа, которая будет усечена в базе данных до 32 первых символов, соответствующих 32 первым байтам $s. Вы можете подумать, что MySQL 5 ведет себя как MySQL 4, но на самом деле это вторая причина для того же эффекта.