Spec-Zone.ru › MySQL 8.4

25.2.7.1 Несоблюдение синтаксиса SQL в кластере NDB

Некоторые операторы SQL, относящиеся к определенным функциям MySQL, выдают ошибки при использовании с таблицами NDB, как описано в следующем списке:

  • Временные таблицы. Временные таблицы не поддерживаются. Попытка создания временной таблицы с использованием хранилища NDB или изменение существующей временной таблицы для использования NDB приводит к ошибке Двигатель хранения таблицы 'ndbcluster' не поддерживает опцию создания 'TEMPORARY'.

  • Индексы и ключи в таблицах NDB. Ключи и индексы в таблицах кластера NDB имеют следующие ограничения:

    • Ширина столбца. Попытка создания индекса для столбца таблицы NDB, ширина которого превышает 3072 байта, отклоняется с ошибкой: Указанный ключ был слишком длинным; максимальная длина ключа — 3072 байта.

      Попытка создания индекса для столбца таблицы NDB, ширина которого превышает 3056 байт, завершается предупреждением. В таких случаях статистическая информация не генерируется, что может привести к выбору неэффективного плана выполнения запросов. По этой причине следует, если возможно, сократить длину индекса до менее чем 3056 байт.

    • Столбцы TEXT и BLOB. Невозможно создавать индексы для столбцов таблиц NDB, использующих любой из типов данных TEXT или BLOB.

    • Индексы FULLTEXT. Двигатель хранения NDB не поддерживает индексы FULLTEXT, которые возможны только для таблиц MyISAM и InnoDB.

      Однако можно создавать индексы для столбцов VARCHAR таблиц NDB.

    • Ключи с использованием HASH и NULL. Использование столбцов со значениями NULL в уникальных ключах и первичных ключах означает, что запросы, использующие эти столбцы, обрабатываются как полные сканирования таблицы. Для решения этой проблемы сделайте столбец NOT NULL или пересоздайте индекс без опции USING HASH.

    • Префиксы. Индексы префиксов не поддерживаются; можно индексировать только целые столбцы. (Размер индекса столбца NDB всегда совпадает с шириной столбца в байтах, вплоть до 3072 байт, как описано ранее в этом разделе. Также см. Раздел 25.2.7.6, «Неподдерживаемые или отсутствующие функции в кластере NDB» для получения дополнительной информации.)

    • Столбцы BIT. Столбец BIT не может быть первичным ключом, уникальным ключом или индексом, а также не может быть частью составного первичного ключа, уникального ключа или индекса.

    • Столбцы AUTO_INCREMENT. Как и другие движки хранения MySQL, двигатель хранения NDB может обрабатывать не более одного AUTO_INCREMENT столбца на таблицу, и этот столбец должен быть индексирован. Однако в случае таблицы NDB без явного первичного ключа автоматически определяется и используется столбец AUTO_INCREMENT в качестве “скрытого” первичного ключа. По этой причине нельзя создать таблицу NDB, содержащую столбец AUTO_INCREMENT и не имеющую явного первичного ключа.

      Следующие операторы CREATE TABLE не работают, как показано здесь:

      # No index on AUTO_INCREMENT column; table has no primary key
      # Raises
      mysql> CREATE TABLE n (
          ->     a INT,
          ->     b INT AUTO_INCREMENT
          ->     )
          -> ENGINE=NDB;
      ERROR 1075 (42000): Incorrect table definition; there can be only one auto
      column and it must be defined as a key
      
      # Index on AUTO_INCREMENT column; table has no primary key
      # Raises NDB error
      mysql> CREATE TABLE n (
          ->     a INT,
          ->     b INT AUTO_INCREMENT,
          ->     KEY k (b)
          ->     )
          -> ENGINE=NDB;
      ERROR 1296 (HY000): Got error 4335 'Only one autoincrement column allowed per
      table. Having a table without primary key uses an autoincr' from NDBCLUSTER
      

      Следующий оператор создает таблицу с первичным ключом, столбцом AUTO_INCREMENT и индексом по этому столбцу, и выполняется успешно:

      # Index on AUTO_INCREMENT column; table has a primary key
      mysql> CREATE TABLE n (
          ->     a INT PRIMARY KEY,
          ->     b INT AUTO_INCREMENT,
          ->     KEY k (b)
          ->     )
          -> ENGINE=NDB;
      Query OK, 0 rows affected (0.38 sec)
      
  • Ограничения на внешние ключи. Поддержка ограничений внешних ключей в NDB 8.4 сопоставима с поддержкой в InnoDB, с учетом следующих ограничений:

    • Каждый столбец, указанный как внешний ключ, требует явного уникального ключа, если это не первичный ключ таблицы.

    • ON UPDATE CASCADE не поддерживается, когда ссылка указывает на первичный ключ родительской таблицы.

      Это связано с тем, что обновление первичного ключа реализуется как удаление старой строки (содержащей старый первичный ключ) и вставка новой строки (с новым первичным ключом). Это не видно ядру NDB, которое рассматривает эти две строки как одинаковые и, следовательно, не может знать, что это обновление должно быть каскадировано.

    • ON DELETE CASCADE также не поддерживается, если дочерняя таблица содержит один или несколько столбцов любого из типов TEXT или BLOB. (Ошибка #89511, ошибка #27484882)

    • SET DEFAULT не поддерживается. (Также не поддерживается движком InnoDB.)

    • Ключевое слово NO ACTION принимается, но обрабатывается как RESTRICT. NO ACTION, являющееся стандартным ключевым словом SQL, является значением по умолчанию в MySQL 8.4. (То же самое, что и в случае InnoDB.)

    • В более ранних версиях кластера NDB, при создании таблицы с внешним ключом, ссылающимся на индекс в другой таблице, иногда казалось возможным создать внешний ключ, даже если порядок столбцов в индексах не совпадал, так как соответствующая ошибка не всегда возвращалась внутренне. Частичное исправление этой проблемы улучшило используемую внутреннюю ошибку, работающую в большинстве случаев; однако остается возможность возникновения этой ситуации в случае, если родительский индекс является уникальным индексом. (Ошибка #18094360)

    Дополнительную информацию можно найти в Разделе 15.1.20.5, «Ограничения внешних ключей» и Разделе 1.7.3.2, «Ограничения внешних ключей».

  • Кластер NDB и типы данных геометрии. Типы данных геометрии (WKT и WKB) поддерживаются для таблиц NDB. Однако пространственные индексы не поддерживаются.

  • Наборы символов и файлы двоичных журналов. В настоящее время таблицы ndb_apply_status и ndb_binlog_index создаются с использованием набора символов latin1 (ASCII). Поскольку имена двоичных журналов записываются в эту таблицу, файлы двоичных журналов с именами, использующими нелатинские символы, не ссылаются правильно в этих таблицах. Это известная проблема, которую мы исправляем. (Ошибка #50226)

    Для решения этой проблемы используйте только латинские символы при именовании файлов двоичных журналов или при установке параметров --basedir, --log-bin или --log-bin-index.

  • Создание таблиц NDB с пользовательским разбиением. Поддержка пользовательского разбиения в NDB Cluster ограничена разбиением [LINEAR] KEY. Использование любого другого типа разбиения с ENGINE=NDB или ENGINE=NDBCLUSTER в операторе CREATE TABLE приводит к ошибке.

    Существует возможность обойти это ограничение, но использование этого метода в производственных средах не поддерживается. Подробности см. в Пользовательское разбиение и хранилище NDB (NDB Cluster).

    Схема разбиения по умолчанию. Все таблицы NDB Cluster по умолчанию разбиваются по KEY с использованием первичного ключа таблицы в качестве ключа разбиения. Если для таблицы явно не задан первичный ключ, используется вместо него “скрытый” первичный ключ, автоматически созданный хранилищем NDB. Дополнительные обсуждения этих и связанных вопросов см. в разделе 26.2.5, “Разбиение по ключу”.

    Операторы CREATE TABLE и ALTER TABLE, которые могут привести к тому, что таблица NDBCLUSTER с пользовательским разбиением не будет соответствовать одному или обоим из следующих двух требований, запрещены и завершаются с ошибкой:

    1. Таблица должна иметь явный первичный ключ.

    2. Все столбцы, указанные в выражении разбиения таблицы, должны быть частью первичного ключа.

    Исключение. Если таблица NDBCLUSTER с пользовательским разбиением создается с пустым списком столбцов (то есть, используя PARTITION BY [LINEAR] KEY()), то явный первичный ключ не требуется.

    Максимальное количество партиций для таблиц NDBCLUSTER. Максимальное количество партиций, которое можно определить для таблицы NDBCLUSTER при использовании пользовательского разбиения, составляет 8 на группу узлов. (См. раздел 25.2.2, “Узлы NDB Cluster, группы узлов, фрагменты реплик и партиции” для получения дополнительной информации о группах узлов NDB Cluster.)

    DROP PARTITION не поддерживается. Невозможно удалить партиции из таблиц NDB с помощью ALTER TABLE ... DROP PARTITION. Другие расширения разбиения для оператора ALTER TABLE—ADD PARTITION, REORGANIZE PARTITION и COALESCE PARTITION—поддерживаются для таблиц NDB, но используют копирование и поэтому не оптимизированы. См. раздел 26.3.1, “Управление партициями RANGE и LIST” и раздел 15.1.9, “Оператор ALTER TABLE”.

    Выбор партиции. Выбор партиции не поддерживается для таблиц NDB. Дополнительную информацию см. в разделе 26.5, “Выбор партиции”.

  • Тип данных JSON. Тип данных MySQL JSON поддерживается для таблиц NDB в mysqld, поставляемом с NDB 8.4.

    Таблица NDB может иметь не более 3 JSON столбцов.

    API NDB не имеет специальных возможностей для работы с данными JSON, которые он рассматривает просто как данные BLOB. Обработка данных как JSON должна выполняться приложением.

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-8.4-en/mysql-cluster-limitations-syntax.html

Spec-Zone.ru

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