Друзья, объясните кто в теме, такая ситуация:
Делаю колонку с типом CHAR(32) для хранения там строки длинной 32 символа. Таблица на ~ 23,060,801 записей в итоге занимает около 2 гигов.
Меняю тип колонки на VARCHAR(32), таблица начинает занимать 1.6 гига.
Других колонок нет.

Почему CHAR занимает больше чем VARCHAR?
Почему таблица все равно занимает места в 2 раза больше чем данные в ней хранящиеся?

ответ на последний вопрос наверное в кодировке utf8. Хотя все символы в английском алфавите и цифры.

http://www.mysql.ru/docs/man/CHAR.html

(1) оказалось utf8 тут ни при чем. В 1251 то же самое.

АП!

(3) ответ в названии типа. Var это переменная длина

(3) Чего АП?
(2) уже изучил?
"Величины типа CHAR при хранении дополняются справа пробелами до заданной длины.
...
в противоположность CHAR, при хранении величин типа VARCHAR используется только то количество символов, которое необходимо, плюс один байт для записи длины. Хранимые величины пробелами не дополняются, наоборот, концевые пробелы при хранении удаляются"

(0) Не все строки у тебя длинной 32 символы.

Т.е. в случае char место под строку всегда выделяется в том количестве символов, которое указано в скобках. Под varchar - столько места, сколько строка занимает реально, но не более того что указано в скобках.

(4) Друзья, я же конкретный вопрос задал, а не просто описание типов. Зачем мне изучать то что и так давно известно

(6) Откуда это?

(7) Молодец.  Тогда почему (0) противоречит тому что ты написал?

(10) если файл таблицы (или базы, я не знаю как там у мускуля это) открыть на просмотр фаром по F3, там реально какая кодировка текста?

в чем противоречие? Если среди этой кучи строк есть строки меньше 32 символов, то в случае с варчаром таблица будет занимать меньше места. Об этом тут все и толкуют. Так и получилось - было 2, стало 1.6. Все вроде логично

(11) Не проверял еще, но ты уверен что в этом дело? Я под линуксом не знаю каким редактором можно безопасно открыть большой файл, для меня это сложно.

(12) еще раз повторяю, нет там никаких строк меньше 32 символов.

(13) чтобы понять что происходит - нужно увидеть. Запись таблицы наверняка содержит служебку помимо вашей строки - какой-нибудь идентификатор, думаю что он никак не меньше 64 бит, а может и все 128. Вы это учли?

(15) Ну я про это и спрашиваю, что такого я не учел, из-за чего меняется размер таблицы.
Все строки такого вида: "000068486B4921A563F132080AA6FB1D"

ну естественно что строка таблицы содержит служебную информацию для того чтобы база могла работать со строками. А как иначе?

(17) да пусть содержит, я только за! Но от чего размер меняется при смене типа? для CHAR хранится больше служебной информации чем для VARCHAR?

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

возможно, что "играют" страничные выравнивания или еще какие-то особенности хранения данных именно в вашей БД.

(1) utf - это nvarchar и nchar

Вообще-то, если у нас записи в таблице, то длина каждой записи у нас постоянна, а к VarChar будет добавлено ещё два байта длины.
Сервер не может использовать записи переменной длины, так как тогда при увеличении длины строки в поле ему нужно будет перемещать всю запись.
Не забываем ещё про служебную информацию, индексы и т.п.
Также, если вы хотите что-то сравнивать, то нужно сначала создать таблицу, а потом её заполнить.
P.S. если у вас UTF-8, то для CHAR могут выделить по три байта на символ, а вот что там выделяется под VarChar - нужно смотреть - вполне вероятно, что два байта.

Ну ладно. Будем считать что CHAR просто устаревший, и на него разработчики забили.

Всем спасибо, темку можно грохнуть

(22) не буду спорить, но некоторые источники утверждают, что в случае с VARCHAR при хранении количество используемой памяти все же зависит от фактической длины строки. Например здесь: http://phpclub.ru/mysql/doc/char.html. А такая ли уж великая проблема перемещение записи, если есть возможность огромной экономии пространства? там же могут быть десятки раз в случае массива строк сильно различающихся длин.

(24) У версионников, типа FireBird действительно так - у них при изменении даже одного поля пишется новая версия записи и в другое место.
MySql версионником не является, так что в режиме хранилища у него должны быть записи одинаковой длины. Хотя, у него есть MemoryDb, то есть хранение данных в памяти - там, вполне вероятно, что всё зависит от длины строк, и очень велика вероятность, что строки вообще хранятся отдельно от основной записи.
И что касается "переменного хранения", то его смысл в экономии количества передаваемых байтов в процессе обработки - система просто свёртывает все строки переменной длины и получает запись меньшего размера, но в файле выделяется стандартный максимальный размер, просто запись располагается в начале выделенного блока.
P.S. В описании типа данных FireBird было явно сказано, что в случае применения UTF-8 под каждый символ выделяется 3 байта. Правда, если внимательно читать, то становится понятно, что разницы между CHAR и VARCHAR там нет - просто количество байт рассчитывается от количества символов.

Что касается MySql, то у него есть совершенно разные модели хранения, и похоже, что в ISAM действительно переменный размер записи.
http://www.mysql.ru/docs/man/MyISAM.html
Про это здесь написано "свободный блок может быть получен при обновлении записи".

(18) для чар служебной информации не содержится вообще. а еще у тебя есть скрытая служебная колонка.

SELECT Avg( length(поле) )
FROM таблица

(0) Покажи CREATE TABLE.