Пространство увеличилось в таблице MyISAM после изменения типа столбца с INT на SMALLINT и TINYINT

Question

Я пытаюсь сократить пространство, занимаемое моими таблицами БД, и оптимизировать производительность моей системы. Мне интересно специально оптимизировать таблицу MyISAM с большим объемом данных. Итак, я изменил тип колонки следующим образом:
- от INT (11) до BIT (1) или TINYINT (3) или SMALLINT (6) или MEDIUMINT (9)
- от VARCHAR (...) до CHAR (x), с x наименьшее количество символов полезно

Но результат был неожиданным.
Я побежал следующий запрос до и после моих изменений:

ВЫБРАТЬ table_name AS "Таблица", круглые (((data_length + index_length)/1024/1024), 2) "Размер в мегабайтах" ОТ information_schema.TABLES WHERE table_schema = "my_schema" AND table_name = "my_table";

Результаты:
- ДО 558 Мб
- ПОСЛЕ 673,96 Мб

пространство увеличивается. Зачем?

Редактировать:
Проблема была CHAR-преобразование. В моем случае VARCHAR занимает меньше места, потому что поля не имеют фиксированного размера, поэтому для фиксированных полей CHAR требуется больше места.
С VARCHAR мой стол занимает 444 Мб.

Answer 1

Изменения должны были помочь.

VARCHAR Изменения должны были пострадать.

Не используйте CHAR, если вы не используете (1) данные постоянной длины, и (2) подходит CHARACTER SET.

VARCHAR реализован как длина 1 или 2 байта, плюс только столько байтов, сколько необходимо для каждой строки.

CHAR(N) всегда занимает M * N байтов: M байт/символ зависит от кодировки: ascii/latin1: 1; utf8: 3, utf8mb4: 4.

Существует очень мало случаев, когда CHAR на самом деле лучше, чем VARCHAR. Вот некоторые из них:

country_code CHAR(2) CHARACTER SET ascii, 
md5 CHAR(32) CHARACTER SET ascii, -- packing into BINARY(16) would be tighter 
zip_code CHAR(5) CHARACTER SET ascii, -- MEDIUMINT(5) UNSIGNED ZEROFILL would be tighter 
uuid CHAR(36) CHARACTER SET ascii, -- Could be packed into BINARY(16) 

Хммм ... Это все, о чем я могу думать в данный момент.

И нет, MyISAM делает не выгоду от «ФИКСИРОВАННОГО» вместо «ДИНАМИЧЕСКОГО», за исключением редких случаев. Поскольку VARCHAR меньше, меньше ввода-вывода; I/O является основной стоимость обработки данных.

Далее: Забудьте о MyISAM и перейдите к InnoDB.