15.1.21 CREATE TABLESPACE Statement — MySQL 8.4

15.1.21 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»). С помощью этого оператора создается и добавляется один файл данных в табличное пространство. Дополнительные файлы данных могут быть добавлены в табличное пространство с помощью оператора ALTER TABLESPACE (см. Раздел 15.1.10, «ALTER TABLESPACE Оператор»).

Примечание

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

К табличному пространству, которое должно быть создано с помощью параметра USE LOGFILE GROUP, должна быть назначена группа файлов журнала из одного или нескольких UNDO файлов журнала. logfile_group должна быть существующей группой файлов журнала, созданной с помощью CREATE LOGFILE GROUP (см. Раздел 15.1.16, «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 Server выдает предупреждение, когда выполняется такое округление. Округленные значения также используются ядром 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). Если это необходимо, движок хранения добавляет расширение файла. Расширение файла .ibd добавляется для файлов данных общего табличного пространства InnoDB. В среде репликации имя файла данных, созданное на сервере источника репликации, не такое же, как имя файла данных, созданное на реплике.

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

Файлы данных NDB. Табличное пространство NDB поддерживает несколько файлов данных, которые могут иметь любые допустимые имена файлов; дополнительные файлы данных могут быть добавлены к табличному пространству NDB Кластер после его создания с помощью оператора 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 равен значению 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 8.4 поддерживается только движок хранения 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 табличным пространствам не поддерживается. К общим табличным пространствам относятся 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 перед удалением самого табличного пространства. Перед удалением табличного пространства NDB Cluster необходимо также удалить все его данные файлы с помощью одной или нескольких команд ALTER TABLESPACE ... DROP DATATFILE. См. раздел 25.6.11.1, «Объекты данных 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

Предположим, что вы хотите создать табличное пространство NDB Cluster Disk Data с именем 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)

Теперь вы можете создать таблицу данных диска, используя инструкцию 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 Cluster. Вы можете проверить, что файлы данных были созданы, и получить информацию о них, запросив таблицу схемы информации 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».