Я нашел способ обойти эту проблему, а также кое-что из объяснения.
После просмотра структуры таблицы в шестнадцатеричном редакторе (на моих машинах Linux они были расположены в /var/lib/mysql/[DATABASE NAME]/[TABLE NAME].MYD
),Я обнаружил, что во всех случаях записи создавались с использованием минимум 7 байтов для строки, независимо от используемых типов данных.Любые дополнительные байты, которые не использовались таблицей, были обнулены.
Вот пример с меньшим набором данных для иллюстрации:
mysql> describe int_test_2;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id | int(11) | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
1 row in set (0.00 sec)
mysql> select * from int_test_2;
+------+
| id |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
Глядя на этого парня в шестнадцатеричном редакторе,мы видим:
fd01 0000 0000 00fd 0200 0000 0000
Используя информацию из ссылки Нео, я смог расшифровать эту строку:
fd
Запись битов заголовка. 01000000
Целочисленное значение "1" (младший порядковый номер) 0000
Потерянное пространство! fd
Запись битов заголовка. 02000000
Целочисленное значение "2" (little endian) 0000
Потраченное впустую пространство!
Однако обратите внимание на следующее:
mysql> alter table int_test_2 MAX_ROWS=50000000, AVG_ROW_LENGTH=4;
Query OK, 2 rows affected (0.01 sec)
Records: 2 Duplicates: 0 Warnings: 0
Теперь файл MYD выглядит следующим образом:
fd01 0000 00fd 0200 0000
То есть используются правильные размеры.