Known Limitations of NDB Cluster ) ENGINE = NDB, The following query on  t  causes a shared read lock, because it uses a unique key lookup: SELECT * FROM t WHERE c = 1; However, none of the four queries shown here causes a shared read lock: This is because, of these four queries, the first uses an index scan, the second and third use table scans, and the fourth, while using a primary key lookup, does not retrieve the value of any  BLOB  or TEXT  columns. You can help minimize issues with shared read locks by avoiding queries that use unique key lookups that retrieve  BLOB  or  TEXT  columns, or, in cases where such queries are not avoidable, by committing transactions as soon as possible afterward. One workaround which can be used to bypass potentially blocking reads is to force the SQL node to ignore the unique index when performing the read. This can be done by using the  IGNORE INDEX index hint as part of the  SELECT  statement reading the table (see Section 8.9.4, “Index Hints” ). Because the MySQL server creates a shadowing ordered index for every unique index created in  NDB , this lets the ordered index be read instead, and avoids unique index access locking. The resulting read is as consistent as a committed read by primary key, returning the last committed value at the time the row is read. Reading via an ordered index makes less efficient use of resources in the cluster, and may have higher latency. It is also possible to avoid using the unique index for access by querying for ranges rather than for unique values. This behavior differs from that of other transactional storage engines such as  InnoDB  that may roll back individual statements. 3970 • Rollbacks.   There are no partial transactions, and no partial rollbacks of transactions. A duplicate key or similar error causes the entire transaction to be rolled back. • Unique key lookups and transaction isolation.   Unique indexes are implemented in  NDB  using a hidden index table which is maintained internally. When a user-created  NDB  table is accessed using a unique index, the hidden index table is first read to find the primary key that is then used to read the user-created table. To avoid modification of the index during this double-read operation, the row found in the hidden index table is locked. When a row referenced by a unique index in the user-created  NDB table is updated, the hidden index table is subject to an exclusive lock by the transaction in which the update is performed. This means that any read operation on the same (user-created)  NDB  table must wait for the update to complete. This is true even when the transaction level of the read operation is READ COMMITTED . SELECT * FROM t WHERE b = 1; SELECT * FROM t WHERE d = ’1’; SELECT * FROM t; SELECT b,c WHERE a = 1; • Transactions and memory usage.  As noted elsewhere in this chapter, NDB Cluster does not handle large transactions well; it is better to perform a number of small transactions with a few operations each than to attempt a single large transaction containing a great many operations. Among other considerations, large transactions require