Spec-Zone.ru › MySQL 9.2

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 9.2 сравнима с поддержкой InnoDB, с учетом следующих ограничений:

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

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

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

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

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

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

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

    Для получения дополнительной информации см. Раздел 15.1.21.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 Statement».

    Выбор раздела. Выбор раздела не поддерживается для таблиц NDB. Дополнительные сведения см. в Разделе 26.5, «Выбор раздела».

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

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

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

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

Spec-Zone.ru

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