Spec-Zone.ru › MySQL 9.2

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

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

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

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

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

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

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

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

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

Несмотря на различия в структуре хранения на диске, внутренние 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 Size Requirement Estimator» для получения дополнительной информации.

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

Тип данных Требуемое хранение
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 оптимизирует хранение для наборов символов переменной длины. См. Характеристики хранения формата строки COMPACT. В противном случае, 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 < 28
BLOB, TEXT L + 2 байта, где L < 216
MEDIUMBLOB, MEDIUMTEXT L + 3 байта, где L < 224
LONGBLOB, LONGTEXT L + 4 байта, где L < 232
ENUM('value1','value2',...) 1 или 2 байта в зависимости от количества значений перечисления (максимум 65 535 значений)
SET('value1','value2',...) 1, 2, 3, 4 или 8 байтов, в зависимости от количества элементов множества (максимум 64 элемента)

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

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

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. Размер строк в этой второй таблице определяется точным типом столбца, как показано в следующей таблице:

Тип Размер фрагмента BLOB
BLOB, TEXT 2000
MEDIUMBLOB, MEDIUMTEXT 4000
LONGBLOB, LONGTEXT 13948
JSON 8100

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

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

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

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

Размер объекта SET определяется количеством различных элементов набора. Если размер набора равен N, объект занимает (N+7)/8 байта, округлённых до 1, 2, 3, 4 или 8 байтов. У SET может быть максимум 64 элемента. Подробнее см. Раздел 13.3.7, «Тип 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.

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-9.2-en/storage-requirements.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API