17.1.6.3. Пределы, Касающиеся Обработки Транзакции в MySQL Cluster

Для любого SELECT от таблицы MySQL Cluster: Если SELECT включает a BLOB или TEXT столбец, READ COMMITTED уровень изоляции транзакции преобразовывается в чтение с блокировкой чтения. Это делается, чтобы гарантировать непротиворечивость.

Для любого SELECT который использует поиск уникального ключа, чтобы получить любые столбцы, которые используют любой из BLOB или TEXT типы данных и это выполняются в пределах транзакции, совместно используемая блокировка чтения сохранена на таблице для продолжительности транзакции — то есть, пока транзакция или не фиксируется или прерывается.

Эта проблема не происходит для запросов, против которых использование индексирует или сканирования таблицы, даже NDB табличное наличие BLOB или TEXT столбцы.

Например, рассмотрите таблицу t определенный следующим CREATE TABLE оператор:

CREATE TABLE t (    a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,    b INT NOT NULL,    c INT NOT NULL,    d TEXT,    INDEX i(b),    UNIQUE KEY u(c)) ENGINE = NDB,

Любой из следующих запросов на t вызывает совместно используемую блокировку чтения, потому что первый запрос использует поиск первичного ключа и второе использование поиск уникального ключа:

SELECT * FROM t WHERE a = 1;SELECT * FROM t WHERE c = 1;

Однако, ни один из четырех запросов, показанных здесь, не вызывает совместно используемую блокировку чтения:

SELECT * FROM t WHERE b 1;SELECT * FROM t WHERE d = '1';SELECT * FROM t;SELECT b,c WHERE a = 1; 

Это - то, потому что этих четырех запросов первое использование индексировать сканирование, вторые и третьи сканирования таблицы использования, и четвертое, используя поиск первичного ключа, не получает значение любого BLOB или TEXT столбцы.

Можно помочь минимизировать проблемы с совместно используемыми блокировками чтения, избегая запросов, которые используют поиски уникального ключа, которые получают BLOB или TEXT столбцы, или, в случаях, где такие запросы не преодолимы, фиксируя транзакции как можно скорее позже.