Форум MySQL

Доброе утро всем.

Не подскажите, что такое "utf8mb4_general_ci" в phpMyAdmin? Раньше не было. Я так понимаю "mb" уж тут очень похоже на mb_strtolower, к примеру.

UTF8 содержит три байта на символ, что не в полной мере отражает такие языки как японский, к примеру. Новая версия UTF содержит четыре байта на символ, это и есть utf8mb4.
http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html

А в плане памяти?

Памяти чего?

Памяти в целом, на одни и теже данные. Какой вариант будет меньше по объёму весить.

Память, это когда вы будете получать данные и работать с ними, а база, это файлы на жестком диске, занимающие объем.
А вы напишите вот такую строку: "слово word" и сохраните в UTF8, а затем полученное просмотрите как hex-данные (а можно сказать браузеру и кодировку фиктивную, например, 1251). Под английское "word" тоже по 2 байта (заметьте 2, а не три) отводится как и под русское "слово"?
Это и будет вам ответ. В mb_strtolower, которое совсем не имеет к этому отношения (как к формату), mb - это краткое "мультибайность", то есть от 1 до N.

Для русского и английского ровно тоже самое что и было 2 и 1 байт на символ, соответственно.

Если CHAR не использовать только, и если чадо интересует именно этот размер. )

То есть японский или китайский сейчас база данных не сохраняет или искажает?

Их там разных вариантов, урезанных и не очень столько, что не каждый японец и китаец вам их перечислит... Как бы печатные машинки и клавиатуры всегда содержали в районе 100 клавиш, поэтому работать с несколькими тысячами, а в запущенных случаях (корейский) и десятков тысяч иероглифов нет никаких сил - используется упрощенное письмо. Однако, всякие древние документы нужно печатать так как они есть... вы вот старорусскую запись с древним начертанием символов представляете как набирать, а тем более хранить в базе данных? Вот китайцы и японцы примерно также... т.е. кому-то это, конечно, надо, но массы этим не пользуются совершенно.

Японский и прочие азиатские формы письменности нормально укладываются в 3 байта.
4 байтами кодируется такая редкость, которую и за всю жизнь не встретишь-то, не говоря уже о применении в реальных проектах. А те 0.0009% разработчиков, кому всё-таки пришлось столкнуться, наверняка знают об этих тонкостях.

> Памяти в целом, на одни и теже данные. Какой вариант будет меньше по объёму весить.
На диске эти данные будут одинакового размера. Но могут возникнуть проблемы при работе с временными таблицами, которые mysql любит создавать по поводу и без (например при группировках или сортировках). Довольно часто mysql создаёт временные таблицы в памяти для собственных внутренних нужд и для строковых полей в таких таблицах выделяется фиксированное (максимально возможное для указанного типа поля) количество памяти. Например для VARCHAR(10) выделится 31 байт при использовании сопоставления utf8_general_ci, тогда как utf8mb4_general_ci раздуется до 41 байта. Из-за этого размер такой временной таблицы может превысить максимальный и тогда она сконвертируется во временную таблицу на жестком диске. Во тут-то мы и получим нехилые тормоза.

Кстати говоря, любители ставить тип поля VARCHAR(255) для полей, строки в которых заведомо не будут превышать какое-то малое значение (ну например для хранения MD5 хеша в шестнадцатиричном виде), оказываются в ауте на более-менее заметных нагрузках на базу из-за этих нюансов.

Спасибо, буду знать.

Интересно!
Не дадите несколько ссылок почитать о подобных неочевидных хитростях?

Во-первых — http://dev.mysql.com/doc/refman/5.5/en/index.html :)
Его нужно обязательно прочитать с начала до конца хотя бы по-диагонали, чтобы потом примерно знать что вообще есть в mysql и где что искать и смотреть, если возникнет необходимость.

Во-вторых — книга High Performance MySQL от Пети Зайцева и Ко. Must read для любого разработчика, имеющего дело с высокими нагрузками. Просто любопытствующие могут прочитать по-диагонали выборочные главы.

Ну и гугл, как универсальный справочник обо всём на свете :)