15.1.22 CREATE TABLESPACE Statement — MySQL 9.2

15.1.22 Оператор CREATE TABLESPACE

CREATE [UNDO] TABLESPACE tablespace_name

  InnoDB and NDB:
    [ADD DATAFILE 'file_name']
    [AUTOEXTEND_SIZE [=] value]

  InnoDB only:
    [FILE_BLOCK_SIZE = value]
    [ENCRYPTION [=] {'Y' | 'N'}]

  NDB only:
    USE LOGFILE GROUP logfile_group
    [EXTENT_SIZE [=] extent_size]
    [INITIAL_SIZE [=] initial_size]
    [MAX_SIZE [=] max_size]
    [NODEGROUP [=] nodegroup_id]
    [WAIT]
    [COMMENT [=] 'string']

  InnoDB and NDB:
    [ENGINE [=] engine_name]

  Reserved for future use:
    [ENGINE_ATTRIBUTE [=] 'string']

Этот оператор используется для создания табличного пространства. Точный синтаксис и семантика зависят от используемого движка хранения. В стандартных выпусках MySQL это всегда табличное пространство InnoDB. MySQL NDB Cluster также поддерживает табличные пространства, использующие движок хранения NDB.

Учетные данные для InnoDB

Для создания обычных табличных пространств или пространств отмены используется синтаксис CREATE TABLESPACE. Для создания пространства отмены необходимо указать ключевое слово UNDO.

Обычное табличное пространство — это общее табличное пространство. Оно может содержать несколько таблиц и поддерживает все форматы строк таблиц. Обычные табличные пространства могут создаваться в расположении, относительном к каталогу данных или независимом от него.

После создания обычного табличного пространства InnoDB используйте оператор CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name или ALTER TABLE tbl_name TABLESPACE [=] tablespace_name для добавления таблиц в табличное пространство. Дополнительную информацию см. в Разделе 17.6.3.3, «Общие табличные пространства».

Пространства отмены содержат журналы отмены. Пространства отмены могут быть созданы в выбранном расположении, указав полный путь к файлу данных.

Дополнительную информацию см. в Разделе 17.6.3.4, «Пространства отмены».

Учетные данные для NDB Cluster

Этот оператор используется для создания табличного пространства, которое может содержать один или несколько файлов данных, предоставляя место для хранения таблиц NDB Cluster Disk Data (см. Раздел 25.6.11, «Таблицы NDB Cluster Disk Data»). С помощью этого оператора создается и добавляется один файл данных в табличное пространство. Дополнительные файлы данных могут быть добавлены в табличное пространство с помощью оператора ALTER TABLESPACE (см. Раздел 15.1.10, «Оператор ALTER TABLESPACE»).

Примечание

Все объекты NDB Cluster Disk Data используют один и тот же пространственный префикс. Это означает, что каждый объект Disk Data должен иметь уникальное имя (а не просто каждый объект Disk Data данного типа). Например, вы не можете иметь табличное пространство и группу файлов журнала с одинаковым именем или табличное пространство и файл данных с одинаковым именем.

Для создаваемого табличного пространства должна быть назначена группа файлов журнала, содержащая один или несколько UNDO файлов журналов, с помощью USE LOGFILE GROUP-запроса. logfile_group должна быть существующей группой файлов журнала, созданной с помощью CREATE LOGFILE GROUP (см. Раздел 15.1.17, «Оператор CREATE LOGFILE GROUP»). Несколько табличных пространств могут использовать одну и ту же группу файлов журнала для UNDO-логирования.

При установке EXTENT_SIZE или INITIAL_SIZE вы можете дополнительно указать число с однобуквенным сокращением порядка величины, аналогичным сокращениям, используемым в my.cnf. Как правило, это одна из букв M (для мегабайт) или G (для гигабайт).

INITIAL_SIZE и EXTENT_SIZE подвергаются округлениям следующим образом:

EXTENT_SIZE округляется до ближайшего целого кратного 32 КБ.
INITIAL_SIZE округляется вниз до ближайшего целого кратного 32 КБ; этот результат округляется до ближайшего целого кратного EXTENT_SIZE (после любого округления).

Примечание

NDB резервирует 4% табличного пространства для операций перезапуска узлов данных. Это зарезервированное пространство не может использоваться для хранения данных.

Описанное выше округление выполняется явно, и сервер MySQL выдает предупреждение, когда выполняется такое округление. Округленные значения также используются ядром NDB для расчета значений столбца INFORMATION_SCHEMA.FILES и других целей. Однако, чтобы избежать неожиданных результатов, рекомендуется всегда использовать целые кратные 32 КБ при указании этих параметров.

При использовании CREATE TABLESPACE с ENGINE [=] NDB на каждом узле данных кластера создается табличное пространство и соответствующий файл данных. Вы можете проверить, были ли созданы файлы данных, и получить информацию о них, запросив таблицу схемы информации FILES. (См. пример позже в этом разделе.)

(См. Раздел 28.3.15, «Таблица INFORMATION_SCHEMA FILES».)

Параметры

ADD DATAFILE: Определяет имя файла данных табличного пространства. Этот параметр всегда необходим при создании табличного пространства NDB; для InnoDB он требуется только при создании табличного пространства отката. file_name, включая любой указанный путь, должны быть заключены в одинарные или двойные кавычки. Имена файлов (без учёта расширения) и имена каталогов должны иметь длину не менее одного байта. Имена файлов и каталогов нулевой длины не поддерживаются.

Поскольку существуют значительные различия в том, как InnoDB и NDB обрабатывают файлы данных, два движка хранения рассматриваются отдельно в последующем обсуждении.

Файлы данных InnoDB. Табличное пространство InnoDB поддерживает только один файл данных, имя которого должно содержать расширение .ibd.

Чтобы поместить файл данных общего табличного пространства InnoDB в местоположение вне каталога данных, укажите полный путь или путь, относительный к каталогу данных. Для табличных пространств отката разрешён только полный путь. Если путь не указан, общее табличное пространство создаётся в каталоге данных. Табличное пространство отката, созданное без указания пути, создаётся в каталоге, определённом переменной innodb_undo_directory. Если innodb_undo_directory не установлена, табличные пространства отката создаются в каталоге данных.

Чтобы избежать конфликтов с неявно созданными табличными пространствами с файлом на таблицу, создание общего табличного пространства InnoDB в подкаталоге каталога данных не поддерживается. При создании общего табличного пространства или табличного пространства отката за пределами каталога данных каталог должен существовать и быть известным InnoDB до создания табличного пространства. Чтобы сделать каталог известным InnoDB, добавьте его в значение innodb_directories или в одно из переменных, значения которых добавляются к значению innodb_directories. innodb_directories — это переменная только для чтения. Для её настройки требуется перезапуск сервера.

Если оговорка ADD DATAFILE не указана при создании табличного пространства InnoDB, файл данных табличного пространства с уникальным именем создаётся неявно. Уникальное имя файла представляет собой 128-битный UUID, отформатированный в пять групп шестнадцатеричных чисел, разделённых дефисами (aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee). Расширение файла добавляется, если это необходимо движку хранения. Для файлов данных общего табличного пространства InnoDB добавляется расширение .ibd. В среде репликации имя файла данных, созданное на сервере источника репликации, не совпадает с именем файла данных, созданным на реплике.

Оговорка ADD DATAFILE не допускает циклических ссылок на каталоги при создании табличного пространства InnoDB. Например, циклическая ссылка на каталог (/../) в следующем операторе не допускается:
```
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd';
```
Исключение из этого ограничения существует в Linux, где циклическая ссылка на каталог разрешена, если предыдущий каталог является символической ссылкой. Например, путь к файлу данных в приведённом выше примере разрешён, если any_directory является символической ссылкой. (По-прежнему разрешены пути к файлам данных, начинающиеся с '../'.)

Файлы данных NDB. Табличное пространство NDB поддерживает несколько файлов данных, которые могут иметь любые допустимые имена файлов; дополнительные файлы данных могут быть добавлены в табличное пространство NDB Cluster после его создания с помощью оператора ALTER TABLESPACE.

Файл данных табличного пространства NDB по умолчанию создаётся в каталоге файловой системы узла данных — то есть в каталоге с именем ndb_nodeid_fs/TS в каталоге данных узла данных (DataDir), где nodeid — это NodeId узла данных. Чтобы разместить файл данных в другом месте, помимо умолчания, укажите абсолютный путь к каталогу или путь, относительный к умолчанию. Если указанный каталог не существует, NDB пытается его создать; учётная запись системного пользователя, под которой выполняется процесс узла данных, должна иметь соответствующие права.

Примечание

При определении пути, используемого для файла данных, NDB не расширяет символ ~ (тильда).

При выполнении нескольких узлов данных на одном физическом узле применяются следующие соображения:
- Вы не можете указать абсолютный путь при создании файла данных.
- Невозможно создать файлы данных табличного пространства за пределами каталога файловой системы узла данных, если каждый узел данных не имеет отдельного каталога данных.
- Если каждый узел данных имеет свой каталог данных, файлы данных можно создать в любом месте этого каталога.
- Если каждый узел данных имеет свой каталог данных, возможно создание файла данных вне каталога данных узла с помощью относительного пути, при условии, что этот путь разрешается в уникальное местоположение в файловой системе хоста для каждого узла данных, выполняющегося на этом хосте.
FILE_BLOCK_SIZE: Этот параметр, специфичный для общих табличных пространств InnoDB, и игнорируется NDB, определяет размер блока для файла данных табличного пространства. Значения могут быть указаны в байтах или килобайтах. Например, размер блока файла 8 килобайт может быть указан как 8192 или 8К. Если этот параметр не указан, FILE_BLOCK_SIZE по умолчанию принимает значение innodb_page_size. FILE_BLOCK_SIZE требуется, если вы намерены использовать табличное пространство для хранения сжатых таблиц InnoDB (ROW_FORMAT=COMPRESSED). В этом случае вы должны определить параметр FILE_BLOCK_SIZE при создании табличного пространства.

Если FILE_BLOCK_SIZE равно значению innodb_page_size, табличное пространство может содержать только таблицы с нескомпрессированным форматом строк (COMPACT, REDUNDANT и DYNAMIC). Таблицы с COMPRESSED форматом строк имеют размер физической страницы, отличный от нескомпрессированных таблиц. Поэтому сжатые и нескомпрессированные таблицы не могут сосуществовать в одном табличном пространстве.

Для того, чтобы общее табличное пространство содержало сжатые таблицы, необходимо указать FILE_BLOCK_SIZE, и значение FILE_BLOCK_SIZE должно быть действительным размером сжатой страницы по отношению к значению innodb_page_size. Также, размер физической страницы сжатой таблицы (KEY_BLOCK_SIZE) должен быть равен FILE_BLOCK_SIZE/1024. Например, если innodb_page_size=16K, и FILE_BLOCK_SIZE=8K, размер KEY_BLOCK_SIZE таблицы должен быть 8. Дополнительную информацию см. в Разделе 17.6.3.3, «Общие табличные пространства».
USE LOGFILE GROUP: Требуется для NDB, это имя группы файлов журнала, предварительно созданной с помощью CREATE LOGFILE GROUP. Не поддерживается для InnoDB, где это приводит к ошибке.
EXTENT_SIZE: Этот параметр специфичен для NDB и не поддерживается InnoDB, где он приводит к ошибке. EXTENT_SIZE задаёт размер, в байтах, экстентов, используемых любыми файлами, принадлежащими табличному пространству. Значение по умолчанию составляет 1 МБ. Минимальный размер составляет 32 КБ, а теоретический максимальный размер — 2 ГБ, хотя практический максимальный размер зависит от ряда факторов. В большинстве случаев изменение размера экстентов не оказывает ощутимого влияния на производительность, и рекомендуется использовать значение по умолчанию во всех случаях, кроме самых необычных.

Экстент — это единица выделения дискового пространства. Один экстент заполняется данными до тех пор, пока не будет использован другой экстент. Теоретически, до 65 535 (64 КБ) экстентов могут использоваться в каждом файле данных; однако рекомендуемый максимум составляет 32 768 (32 КБ). Рекомендуемый максимальный размер одного файла данных составляет 32 ГБ — то есть 32 КБ экстентов × 1 МБ на экстент. Кроме того, после выделения экстента заданному разделу, он не может использоваться для хранения данных из другого раздела; экстент не может хранить данные более чем из одного раздела. Это означает, например, что табличное пространство, имеющее единственный файл данных, размер INITIAL_SIZE (описанный в следующем пункте) которого составляет 256 МБ, а EXTENT_SIZE — 128 МБ, имеет всего два экстенты и поэтому может использоваться для хранения данных, максимум, из двух различных разделов таблиц данных на диске.

Вы можете увидеть, сколько экстентов осталось свободными в данном файле данных, запросив таблицу Информационной схемы FILES, и таким образом получить оценку оставшегося свободного места в файле. Более подробное обсуждение и примеры см. в Разделе 28.3.15, «Таблица INFORMATION_SCHEMA FILES».
INITIAL_SIZE: Этот параметр специфичен для NDB и не поддерживается InnoDB, где он приводит к ошибке.

Параметр INITIAL_SIZE устанавливает общий размер в байтах файла данных, который был указан с помощью ADD DATATFILE. После создания этого файла его размер изменить нельзя; однако вы можете добавить дополнительные файлы данных в табличное пространство с помощью ALTER TABLESPACE ... ADD DATAFILE.

INITIAL_SIZE необязателен; его значение по умолчанию равно 134217728 (128 МБ).

В 32-битных системах максимальное поддерживаемое значение для INITIAL_SIZE составляет 4294967296 (4 ГБ).

AUTOEXTEND_SIZE: Определяет величину, на которую InnoDB увеличивает размер табличного пространства при его заполнении. Значение должно быть кратно 4 МБ. Значение по умолчанию — 0, что приводит к расширению табличного пространства в соответствии с неявным поведением по умолчанию. Дополнительную информацию см. в разделе 17.6.3.9 «Конфигурация AUTOEXTEND_SIZE табличного пространства».

Не оказывает никакого влияния в любых выпусках MySQL NDB Cluster, независимо от используемого движка хранения.
MAX_SIZE: В настоящее время игнорируется MySQL; зарезервировано для возможного использования в будущем. Не оказывает никакого влияния в любых выпусках MySQL или MySQL NDB Cluster, независимо от используемого движка хранения.
NODEGROUP: В настоящее время игнорируется MySQL; зарезервировано для возможного использования в будущем. Не оказывает никакого влияния в любых выпусках MySQL или MySQL NDB Cluster, независимо от используемого движка хранения.
WAIT: В настоящее время игнорируется MySQL; зарезервировано для возможного использования в будущем. Не оказывает никакого влияния в любых выпусках MySQL или MySQL NDB Cluster, независимо от используемого движка хранения.
COMMENT: В настоящее время игнорируется MySQL; зарезервировано для возможного использования в будущем. Не оказывает никакого влияния в любых выпусках MySQL или MySQL NDB Cluster, независимо от используемого движка хранения.
Оператор ENCRYPTION включает или отключает шифрование данных на уровне страницы для InnoDB общего табличного пространства.

Если оператор ENCRYPTION не указан, то значение параметра default_table_encryption определяет, включено ли шифрование. Оператор ENCRYPTION переопределяет значение параметра default_table_encryption. Однако, если переменная table_encryption_privilege_check включена, то для использования значения оператора ENCRYPTION, отличного от значения параметра default_table_encryption, необходимо разрешение TABLE_ENCRYPTION_ADMIN.

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

При шифровании общего табличного пространства все таблицы, находящиеся в этом табличном пространстве, шифруются. Аналогично, таблица, созданная в зашифрованном табличном пространстве, также будет зашифрована.

Дополнительную информацию см. в разделе 17.13 «Шифрование данных InnoDB на уровне носителя»
ENGINE: Определяет движок хранения, использующий табличное пространство, где engine_name — имя движка хранения. В стандартных выпусках MySQL 9.2 поддерживается только движок хранения InnoDB. MySQL NDB Cluster поддерживает как NDB, так и InnoDB табличные пространства. Значение системной переменной default_storage_engine используется для ENGINE, если этот параметр не указан.
Параметр ENGINE_ATTRIBUTE используется для указания атрибутов табличного пространства для первичных движков хранения. Параметр зарезервирован для будущего использования.

Присваиваемое этому параметру значение должно быть строковым литералом, содержащим корректный JSON-документ или пустую строку (''). Некорректный JSON отклоняется.
```
CREATE TABLESPACE ts1 ENGINE_ATTRIBUTE='{"key":"value"}';
```
Значения ENGINE_ATTRIBUTE могут быть повторены без ошибок. В этом случае используется последнее указанное значение.

Значения ENGINE_ATTRIBUTE не проверяются сервером, и они не очищаются при изменении движка хранения таблицы.

Примечания

Правила именования MySQL табличных пространств см. в разделе 11.2 «Имена объектов схемы». Помимо этих правил, запрещено использование символа косой черты (“/”), а также имена, начинающиеся с innodb_, так как этот префикс зарезервирован для использования системой.
Создание временных общих табличных пространств не поддерживается.
Общие табличные пространства не поддерживают временные таблицы.
Параметр TABLESPACE может использоваться с CREATE TABLE или ALTER TABLE для назначения части таблицы или подчасти таблицы файловому табличному пространству на основе таблиц. Все разделы должны принадлежать одному и тому же движку хранения. Назначение разделов таблиц общим InnoDB табличным пространствам не поддерживается. К общим табличным пространствам относятся системное табличное пространство InnoDB и общие табличные пространства.
Общие табличные пространства поддерживают добавление таблиц любого формата строк с помощью CREATE TABLE ... TABLESPACE. innodb_file_per_table не нужно включать.
innodb_strict_mode не применимо к общим табличным пространствам. Правила управления табличным пространством строго применяются независимо от innodb_strict_mode. Если параметры CREATE TABLESPACE некорректны или несовместимы, операция завершается неудачно независимо от значения innodb_strict_mode. При добавлении таблицы в общее табличное пространство с помощью CREATE TABLE ... TABLESPACE или ALTER TABLE ... TABLESPACE, innodb_strict_mode игнорируется, но оператор оценивается так, как если бы innodb_strict_mode был включен.
Используйте DROP TABLESPACE для удаления табличного пространства. Все таблицы должны быть удалены из табличного пространства с помощью DROP TABLE перед удалением табличного пространства. Перед удалением табличного пространства MySQL NDB Cluster также необходимо удалить все его файлы данных с помощью одного или нескольких операторов ALTER TABLESPACE ... DROP DATATFILE. См. раздел 25.6.11.1 «Объекты данных диска MySQL NDB Cluster».
Все части таблицы InnoDB, добавленной в общее табличное пространство InnoDB, находятся в общем табличном пространстве, включая индексы и страницы BLOB.

Для таблицы NDB, назначенной табличному пространству, на диск сохраняются только те столбцы, которые не индексированы, и фактически используются файлы данных табличного пространства. Индексы и индексированные столбцы для всех таблиц NDB всегда хранятся в памяти.
Аналогично системному табличному пространству, обнуление или удаление таблиц, хранящихся в общем табличном пространстве, создает внутреннее свободное место в общем табличном пространстве, которое может быть использовано только для новых InnoDB данных. Место не возвращается в операционную систему, как это происходит для табличных пространств на основе отдельных файлов.
Общее табличное пространство не связано ни с одной базой данных или схемой.
ALTER TABLE ... DISCARD TABLESPACE и ALTER TABLE ...IMPORT TABLESPACE не поддерживаются для таблиц, принадлежащих общему табличному пространству.
Сервер использует блокировку метаданных уровня табличного пространства для DDL, ссылающегося на общие табличные пространства. В сравнении с этим, сервер использует блокировку метаданных на уровне таблицы для DDL, ссылающегося на табличные пространства на основе отдельных файлов.
Сгенерированное или существующее табличное пространство не может быть изменено на общее табличное пространство.
Нет конфликта между именами общих табличных пространств и именами табличных пространств на основе отдельных файлов. Символ “/”, присутствующий в именах табличных пространств на основе отдельных файлов, запрещен в именах общих табличных пространств.
mysqldump не экспортирует операторы InnoDB CREATE TABLESPACE.

Примеры InnoDB

В этом примере показано создание общего табличного пространства и добавление трех нескомпрессированных таблиц различных форматов строк.

mysql> CREATE TABLESPACE `ts1` ADD DATAFILE 'ts1.ibd' ENGINE=INNODB;

mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1 ROW_FORMAT=REDUNDANT;

mysql> CREATE TABLE t2 (c1 INT PRIMARY KEY) TABLESPACE ts1 ROW_FORMAT=COMPACT;

mysql> CREATE TABLE t3 (c1 INT PRIMARY KEY) TABLESPACE ts1 ROW_FORMAT=DYNAMIC;

В этом примере показано создание общего табличного пространства и добавление сжатой таблицы. В примере предполагается стандартное значение innodb_page_size равное 16 КБ. Значение FILE_BLOCK_SIZE равное 8192 требует, чтобы сжатая таблица имела размер KEY_BLOCK_SIZE равный 8.

mysql> CREATE TABLESPACE `ts2` ADD DATAFILE 'ts2.ibd' FILE_BLOCK_SIZE = 8192 ENGINE=InnoDB;

mysql> CREATE TABLE t4 (c1 INT PRIMARY KEY) TABLESPACE ts2 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

В этом примере показано создание общего табличного пространства без указания оператора ADD DATAFILE, который является необязательным:

mysql> CREATE TABLESPACE `ts3` ENGINE=INNODB;

В этом примере показано создание табличного пространства отката:

mysql> CREATE UNDO TABLESPACE undo_003 ADD DATAFILE 'undo_003.ibu';

Пример NDB

Предположим, что требуется создать табличное пространство данных MySQL NDB Cluster с именем myts, используя файл данных с именем mydata-1.dat. Табличное пространство NDB всегда требует использования группы файлов журнала, состоящей из одного или нескольких файлов журнала отката. В этом примере сначала создается группа файлов журнала с именем mylg, содержащая один файл журнала отката с именем myundo-1.dat, используя оператор CREATE LOGFILE GROUP, показанный здесь:

mysql> CREATE LOGFILE GROUP myg1
    ->     ADD UNDOFILE 'myundo-1.dat'
    ->     ENGINE=NDB;
Query OK, 0 rows affected (3.29 sec)

Теперь вы можете создать табличное пространство, описанное ранее, с помощью следующей команды:

mysql> CREATE TABLESPACE myts
    ->     ADD DATAFILE 'mydata-1.dat'
    ->     USE LOGFILE GROUP mylg
    ->     ENGINE=NDB;
Query OK, 0 rows affected (2.98 sec)

Теперь вы можете создать таблицу Disk Data, используя оператор CREATE TABLE с параметрами TABLESPACE и STORAGE DISK, как показано ниже:

mysql> CREATE TABLE mytable (
    ->     id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    ->     lname VARCHAR(50) NOT NULL,
    ->     fname VARCHAR(50) NOT NULL,
    ->     dob DATE NOT NULL,
    ->     joined DATE NOT NULL,
    ->     INDEX(last_name, first_name)
    -> )
    ->     TABLESPACE myts STORAGE DISK
    ->     ENGINE=NDB;
Query OK, 0 rows affected (1.41 sec)

Важно отметить, что на диске фактически хранятся только столбцы dob и joined из mytable, поскольку столбцы id, lname и fname индексированы.

Как упоминалось ранее, при использовании CREATE TABLESPACE с ENGINE [=] NDB на каждом узле данных кластера NDB создается табличное пространство и соответствующий файл данных. Вы можете проверить, что файлы данных были созданы, и получить информацию о них, запросив таблицу схемы информации FILES, как показано ниже:

mysql> SELECT FILE_NAME, FILE_TYPE, LOGFILE_GROUP_NAME, STATUS, EXTRA
    ->     FROM INFORMATION_SCHEMA.FILES
    ->     WHERE TABLESPACE_NAME = 'myts';

+--------------+------------+--------------------+--------+----------------+
| file_name    | file_type  | logfile_group_name | status | extra          |
+--------------+------------+--------------------+--------+----------------+
| mydata-1.dat | DATAFILE   | mylg               | NORMAL | CLUSTER_NODE=5 |
| mydata-1.dat | DATAFILE   | mylg               | NORMAL | CLUSTER_NODE=6 |
| NULL         | TABLESPACE | mylg               | NORMAL | NULL           |
+--------------+------------+--------------------+--------+----------------+
3 rows in set (0.01 sec)

Дополнительную информацию и примеры см. в разделе 25.6.11.1 «Объекты данных на диске NDB Cluster».