13.7 Data Type Storage Requirements — MySQL 8.4

13.7 Требования к хранению типов данных

Требования к хранению данных таблиц на диске зависят от нескольких факторов. Разные движки хранения представляют типы данных и хранят исходные данные по-разному. Данные таблиц могут быть сжаты, либо для столбца, либо для всей строки, что усложняет расчет требований к хранению для таблицы или столбца.

Несмотря на различия в структуре хранения на диске, внутренние API MySQL, которые общаются и обмениваются информацией о строках таблиц, используют согласованную структуру данных, которая применяется ко всем движкам хранения.

Этот раздел содержит рекомендации и информацию о требованиях к хранению каждого типа данных, поддерживаемого MySQL, включая внутренний формат и размер для движков хранения, использующих фиксированное представление для типов данных. Информация приводится по категориям или движкам хранения.

Внутреннее представление таблицы имеет максимальный размер строки 65 535 байт, даже если движок хранения способен поддерживать строки большего размера. Это число не включает BLOB или TEXT столбцы, которые вносят лишь 9–12 байт в этот размер. Для BLOB и TEXT данных информация хранится во внутренней области памяти, отличной от буфера строки. Различные движки хранения обрабатывают выделение и хранение этих данных различными способами, в соответствии с используемым методом обработки соответствующих типов. Для получения дополнительной информации см. Главу 18, Альтернативные движки хранения и Раздел 10.4.7, «Ограничения количества столбцов таблицы и размера строки».

Требования к хранению таблиц InnoDB

См. Раздел 17.10, «Форматы строк InnoDB» для получения информации о требованиях к хранению InnoDB таблиц.

Требования к хранению таблиц NDB

Важно

NDB таблицы используют выравнивание по 4 байтам; всё хранение NDB данных выполняется кратно 4 байтам. Таким образом, значение столбца, которое обычно занимает 15 байт, требует 16 байт в NDB таблице. Например, в NDB таблицах, TINYINT, SMALLINT, MEDIUMINT и INTEGER (INT) типов столбцов требуют по 4 байта хранения на запись из-за фактора выравнивания.

Каждый столбец BIT(M) занимает M битов места хранения. Хотя отдельный столбец BIT не выровнен по 4 байтам, NDB резервирует 4 байта (32 бита) на строку для первых 1–32 битов, необходимых для столбцов BIT, затем ещё 4 байта для битов 33–64 и так далее.

Хотя сам NULL не требует никакого места хранения, NDB резервирует 4 байта на строку, если определение таблицы содержит любые столбцы, допускающие NULL, до 32 NULL столбцов. (Если таблица NDB Cluster определяется с более чем 32 NULL столбцами до 64 NULL столбцов, то резервируется 8 байт на строку.)

Каждая таблица, использующая движок хранения NDB, требует первичного ключа; если вы не определяете первичный ключ, NDB создает «скрытый» первичный ключ. Этот скрытый первичный ключ потребляет 31–35 байт на запись таблицы.

Вы можете использовать Perl-скрипт ndb_size.pl для оценки требований к хранению NDB. Он подключается к текущей базе данных MySQL (не NDB Cluster) и создаёт отчёт о том, сколько места потребовала бы эта база данных, если бы она использовала движок хранения NDB. См. Раздел 25.5.29, «ndb_size.pl — Оценщик требований к размеру NDBCLUSTER» для получения дополнительной информации.

Требования к хранению числовых типов данных

Тип данных	Требуемое хранение
`TINYINT`	1 байт
`SMALLINT`	2 байта
`MEDIUMINT`	3 байта
`INT`, `INTEGER`	4 байта
`BIGINT`	8 байтов
`FLOAT(p)`	4 байта, если 0 <= `p` <= 24, 8 байтов, если 25 <= `p` <= 53
`FLOAT`	4 байта
`DOUBLE [PRECISION]`, `REAL`	8 байтов
`DECIMAL(M,D)`, `NUMERIC(M,D)`	Переменное количество; см. последующее обсуждение
`BIT(M)`	приблизительно (`M`+7)/8 байтов

Значения для столбцов DECIMAL (и NUMERIC) представляются в двоичном формате, который упаковывает девять десятичных (основание 10) цифр в четыре байта. Хранение целой и дробной частей каждого значения определяется отдельно. Каждые девять цифр требуют четыре байта, а «оставшиеся» цифры — некоторую долю от четырёх байтов. Требуемое хранение для дополнительных цифр показано в следующей таблице.

Остаток цифр	Количество байтов
0	0
1	1
2	1
3	2
4	2
5	3
6	3
7	4
8	4

Требования к хранению типов данных даты и времени

Для столбцов TIME, DATETIME и TIMESTAMP требуемое хранение для таблиц, созданных до MySQL 5.6.4, отличается от хранилища для таблиц, созданных начиная с версии 5.6.4. Это связано с изменением в 5.6.4, которое позволяет этим типам иметь дробную часть, что требует от 0 до 3 байтов.

Тип данных	Требуемое хранение до MySQL 5.6.4	Требуемое хранение начиная с MySQL 5.6.4
`YEAR`	1 байт	1 байт
`DATE`	3 байта	3 байта
`TIME`	3 байта	3 байта + хранение дробной части секунд
`DATETIME`	8 байтов	5 байтов + хранение дробной части секунд
`TIMESTAMP`	4 байта	4 байта + хранение дробной части секунд

Начиная с MySQL 5.6.4, хранение для YEAR и DATE остается неизменным. Однако TIME, DATETIME и TIMESTAMP представляются по-другому. DATETIME упаковывается более эффективно, требуя 5, а не 8 байтов для целой части, и все три части имеют дробную часть, требующую от 0 до 3 байтов, в зависимости от точности дробной части секунд хранимых значений.

Точность дробной части секунд	Требуемое хранение
0	0 байтов
1, 2	1 байт
3, 4	2 байта
5, 6	3 байта

Например, TIME(0), TIME(2), TIME(4) и TIME(6) используют 3, 4, 5 и 6 байтов соответственно. TIME и TIME(0) эквивалентны и требуют одинакового хранилища.

Подробную информацию об внутреннем представлении временных значений см. в MySQL Internals: Важные алгоритмы и структуры.

Требования к хранению строк

В следующей таблице M представляет заявленную длину столбца в символах для небинарных типов строк и байтах для бинарных типов строк. L представляет фактическую длину в байтах заданного значения строки.

Тип данных	Требования к хранению
`CHAR(M)`	Семейство компактных форматов строк InnoDB оптимизирует хранение для наборов символов переменной длины. См. Характеристики хранения компактного формата строк. В противном случае, `M` × `w` байт, `<= M <=` 255, где `w` — количество байтов, необходимое для символа максимальной длины в наборе символов.
`BINARY(M)`	`M` байт, 0 `<= M <=` 255
`VARCHAR(M)`, `VARBINARY(M)`	`L` + 1 байт, если значения столбцов требуют 0 − 255 байт, `L` + 2 байта, если значения могут потребовать более 255 байт
`TINYBLOB`, `TINYTEXT`	`L` + 1 байт, где `L` < 2⁸
`BLOB`, `TEXT`	`L` + 2 байта, где `L` < 2¹⁶
`MEDIUMBLOB`, `MEDIUMTEXT`	`L` + 3 байта, где `L` < 2²⁴
`LONGBLOB`, `LONGTEXT`	`L` + 4 байта, где `L` < 2³²
`ENUM('value1','value2',...)`	1 или 2 байта, в зависимости от количества значений перечисления (максимум 65 535 значений)
`SET('value1','value2',...)`	1, 2, 3, 4 или 8 байт, в зависимости от количества членов набора (максимум 64 члена)

Строки переменной длины хранятся с использованием префикса длины плюс данные. Префикс длины требует от одного до четырех байтов в зависимости от типа данных, а значение префикса равно L (длина строки в байтах). Например, хранение значения MEDIUMTEXT требует L байт для хранения значения плюс три байта для хранения длины значения.

Для расчета количества байтов, используемых для хранения конкретного значения столбца CHAR, VARCHAR или TEXT, необходимо учитывать используемый для этого столбца набор символов и наличие многобайтовых символов в значении. В частности, при использовании набора символов UTF-8 Unicode следует учитывать, что не все символы используют одинаковое количество байт. Наборы символов utf8mb3 и utf8mb4 могут потребовать до трех и четырех байт на символ соответственно. Для подробного анализа используемого хранилища для различных категорий utf8mb3 или utf8mb4 символов см. Раздел 12.9 «Поддержка Unicode».

VARCHAR, VARBINARY, а также типы BLOB и TEXT являются типами переменной длины. Для каждого из них требования к хранению зависят от следующих факторов:

Фактическая длина значения столбца
Максимальная возможная длина столбца
Используемый для столбца набор символов, так как некоторые наборы символов содержат многобайтовые символы

Например, столбец VARCHAR(255) может содержать строку с максимальной длиной 255 символов. Предполагая, что столбец использует набор символов latin1 (один байт на символ), фактическое используемое хранилище составляет длину строки (L) плюс один байт для записи длины строки. Для строки 'abcd', L равно 4, а требования к хранению составляют пять байт. Если тот же столбец объявлен с использованием двубайтного набора символов ucs2, требования к хранению составляют 10 байт: длина 'abcd' составляет восемь байт, а столбец требует двух байт для хранения длин, поскольку максимальная длина больше 255 (до 510 байт).

Эффективное максимальное количество байтов, которые могут храниться в столбце VARCHAR или VARBINARY, ограничено максимальным размером строки в 65 535 байт, который делится между всеми столбцами. Для столбца VARCHAR, хранящего многобайтовые символы, эффективное максимальное количество символов меньше. Например, символы utf8mb4 могут потребовать до четырех байт на символ, поэтому столбец VARCHAR, использующий набор символов utf8mb4, может быть объявлен максимум 16 383 символами. См. Раздел 10.4.7 «Ограничения на количество столбцов таблицы и размер строки».

InnoDB кодирует поля фиксированной длины, длина которых больше или равна 768 байтам, как поля переменной длины, которые могут храниться вне страницы. Например, столбец CHAR(255) может превышать 768 байт, если максимальная длина набора символов больше 3, как это имеет место у utf8mb4.

Сетевой движок хранения NDB поддерживает столбцы переменной ширины. Это означает, что столбец VARCHAR в таблице NDB Cluster требует того же объема хранения, что и любой другой движок хранения, за исключением того, что такие значения выравниваются по 4 байтам. Таким образом, строка 'abcd', хранящаяся в столбце VARCHAR(50), используя набор символов latin1, требует 8 байт (вместо 5 байт для того же значения столбца в таблице MyISAM).

Столбцы TEXT, BLOB и JSON реализованы иначе в сетевом движке хранения NDB, где каждая строка в столбце состоит из двух отдельных частей. Одна из них имеет фиксированный размер (256 байт для TEXT и BLOB, 4000 байт для JSON) и фактически хранится в исходной таблице. Другая состоит из любых данных, превышающих 256 байт, которые хранятся в скрытой таблице blob parts. Размер строк во второй таблице определяется точным типом столбца, как показано в следующей таблице:

Тип	Размер blob parts
`BLOB`, `TEXT`	2000
`MEDIUMBLOB`, `MEDIUMTEXT`	4000
`LONGBLOB`, `LONGTEXT`	13948
`JSON`	8100

Это означает, что размер столбца TEXT составляет 256, если size <= 256 (где size представляет размер строки); в противном случае размер составляет 256 + size + (2000 × (size − 256) % 2000).

Никаких blob parts не хранятся отдельно движком NDB для значений столбцов TINYBLOB или TINYTEXT.

Вы можете увеличить размер части NDB столбца NDB до максимального значения 13948, используя NDB_COLUMN в комментарии к столбцу при создании или изменении родительской таблицы. NDB также поддерживает установку размера в строке для столбца TEXT, BLOB или JSON, используя NDB_TABLE в комментарии к столбцу. Дополнительную информацию см. в NDB_COLUMN Options.

Размер объекта ENUM определяется количеством различных значений перечисления. Для перечислений с количеством значений до 255 используется один байт. Для перечислений с количеством значений от 256 до 65 535 используются два байта. См. Раздел 13.3.5, «Тип ENUM».

Размер объекта SET определяется количеством различных элементов набора. Если размер набора равен N, объект занимает (N+7)/8 байта, округлённые до 1, 2, 3, 4 или 8 байтов. SET может иметь максимум 64 элемента. См. Раздел 13.3.6, «Тип SET».

Требования к хранению пространственных типов

MySQL хранит геометрические значения, используя 4 байта для обозначения SRID, за которыми следует представление WKB значения. Функция LENGTH() возвращает занимаемое значение в байтах.

Описания форматов WKB и внутреннего хранения пространственных значений см. в Разделе 13.4.3, «Поддерживаемые форматы пространственных данных».

Требования к хранению JSON

В общем случае, требования к хранению столбца JSON примерно такие же, как и для столбца LONGBLOB или LONGTEXT; то есть, занимаемое место JSON-документом примерно такое же, как для строкового представления документа, хранящегося в столбце одного из этих типов. Однако есть накладные расходы, связанные с двоичным кодированием, включая метаданные и словари, необходимые для поиска отдельных значений, хранящихся в JSON-документе. Например, строка, хранящаяся в JSON-документе, требует от 4 до 10 дополнительных байтов памяти, в зависимости от длины строки и размера объекта или массива, в котором она хранится.

Кроме того, MySQL устанавливает ограничение на размер любого JSON-документа, хранящегося в столбце JSON, которое не может превышать значение max_allowed_packet.