某些與特定 MySQL 功能相關的 SQL 陳述式,在搭配 NDB
資料表使用時會產生錯誤,如下列清單所述
暫存資料表。 不支援暫存資料表。嘗試建立使用
NDB
儲存引擎的暫存資料表,或變更現有暫存資料表以使用NDB
,都會因錯誤 資料表儲存引擎 'ndbcluster' 不支援 create 選項 'TEMPORARY' 而失敗。NDB 資料表中的索引和索引鍵。 NDB Cluster 資料表上的索引鍵和索引受限於下列限制
欄寬。 嘗試在寬度大於 3072 位元組的
NDB
資料表欄上建立索引,會因ER_TOO_LONG_KEY
而遭拒:指定的索引鍵過長;索引鍵最大長度為 3072 位元組。嘗試在寬度大於 3056 位元組的
NDB
資料表欄上建立索引,將會成功但產生警告。在這種情況下,不會產生統計資訊,這表示可能會選取非最佳的執行計畫。因此,如果可能,您應該考慮讓索引長度短於 3056 位元組。FULLTEXT 索引。
NDB
儲存引擎不支援FULLTEXT
索引,這僅適用於MyISAM
和InnoDB
資料表。USING HASH 索引鍵和 NULL。 在唯一索引鍵和主要索引鍵中使用可為 Null 的欄,表示使用這些欄的查詢會以完整資料表掃描的方式處理。若要解決此問題,請將該欄設定為
NOT NULL
,或重新建立不含USING HASH
選項的索引。前置詞。 沒有前置詞索引;只能為整個欄建立索引。(
NDB
欄索引的大小一律與該欄的位元組寬度相同,最多包含 3072 位元組,如本節稍早所述。另請參閱第 25.2.7.6 節「NDB Cluster 中不支援或遺失的功能」,以取得其他資訊。)BIT 欄。
BIT
欄不能是主要索引鍵、唯一索引鍵或索引,也不能是複合主要索引鍵、唯一索引鍵或索引的一部分。AUTO_INCREMENT 欄。 與其他 MySQL 儲存引擎類似,
NDB
儲存引擎每個資料表最多可以處理一個AUTO_INCREMENT
欄,而且這個欄必須建立索引。但是,如果 NDB 資料表沒有明確的主要索引鍵,則會自動定義AUTO_INCREMENT
欄,並將其用作「隱藏」的主要索引鍵。因此,您無法建立具有AUTO_INCREMENT
欄且沒有明確主要索引鍵的NDB
資料表。下列
CREATE TABLE
陳述式無法運作,如下所示# No index on AUTO_INCREMENT column; table has no primary key # Raises ER_WRONG_AUTO_KEY 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 4335 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.0 中對外來索引鍵條件約束的支援與
InnoDB
提供的支援相當,但受限於下列限制每個以外來索引鍵參照的欄,如果不是資料表的主要索引鍵,則都需要明確的唯一索引鍵。
當參照父資料表的主要索引鍵時,不支援
ON UPDATE CASCADE
。這是因為主要索引鍵的更新是以刪除舊資料列(包含舊的主要索引鍵)加上插入新資料列(包含新的主要索引鍵)的方式實作。這對於
NDB
核心來說是不可見的,它會將這兩個資料列視為相同,因此無法知道此更新應該連鎖。如果子資料表包含任何
TEXT
或BLOB
類型的一個或多個欄,則也不支援ON DELETE CASCADE
。(錯誤 #89511,錯誤 #27484882)不支援
SET DEFAULT
。(InnoDB
也不支援。)接受
NO ACTION
關鍵字,但會視為RESTRICT
。NO ACTION
是一個標準的 SQL 關鍵字,是 MySQL 9.0 中的預設值。(與InnoDB
相同。)在舊版 NDB Cluster 中,當建立外來索引鍵參照另一個資料表中的索引的資料表時,有時似乎可以建立外來索引鍵,即使索引中欄的順序不符,原因是因為內部不一定會傳回適當的錯誤。此問題的部分修正改善了內部使用的錯誤,以在大多數情況下運作;但是,在父索引是唯一索引的情況下,仍然可能發生這種情況。(錯誤 #18094360)
如需詳細資訊,請參閱第 15.1.20.5 節「外來索引鍵條件約束」,以及第 1.7.3.2 節「外來索引鍵條件約束」。
NDB Cluster 和幾何資料類型。
NDB
資料表支援幾何資料類型(WKT
和WKB
)。但是,不支援空間索引。字元集和二進位日誌檔案。 目前,
ndb_apply_status
和ndb_binlog_index
資料表是使用latin1
(ASCII) 字元集建立的。由於二進位日誌的名稱會記錄在此資料表中,因此名稱中使用非拉丁字元的二進位日誌檔案不會在此資料表中正確參照。這是我們正努力修正的已知問題。(錯誤 #50226)若要解決此問題,在命名二進位日誌檔案或設定任何
--basedir
、--log-bin
或--log-bin-index
選項時,僅使用 Latin-1 字元。使用使用者定義分割建立 NDB 資料表。 NDB Cluster 中對使用者定義分割的支援僅限於 [
LINEAR
]KEY
分割。在CREATE TABLE
陳述式中將任何其他分割類型與ENGINE=NDB
或ENGINE=NDBCLUSTER
搭配使用都會導致錯誤。可以覆寫此限制,但是不支援在生產設定中使用這種做法。如需詳細資訊,請參閱使用者定義分割和 NDB 儲存引擎 (NDB Cluster)。
預設分割配置。 依預設,所有 NDB Cluster 資料表都會使用資料表的主要索引鍵做為分割索引鍵,以
KEY
進行分割。如果沒有為資料表明確設定主要索引鍵,則會改為使用NDB
儲存引擎自動建立的「隱藏」主要索引鍵。如需這些及相關問題的其他討論,請參閱第 26.2.5 節「索引鍵分割」。如果
CREATE TABLE
和ALTER TABLE
陳述式會導致使用者分割的NDBCLUSTER
資料表未滿足下列其中一項或兩項需求,則不允許且會因錯誤而失敗資料表必須具有明確的主要索引鍵。
資料表分割運算式中列出的所有欄都必須是主要索引鍵的一部分。
例外狀況: 如果使用者分割的
NDBCLUSTER
資料表是使用空的欄位列表建立的(也就是使用PARTITION BY [LINEAR] KEY()
),則不需要明確的主鍵。NDBCLUSTER 資料表的最大分割區數量: 當使用使用者定義分割時,每個節點群組可以為
NDBCLUSTER
資料表定義的最大分割區數量為 8 個。(有關 NDB Cluster 節點群組的更多資訊,請參閱 第 25.2.2 節,「NDB Cluster 節點、節點群組、片段複本和分割區」。)不支援 DROP PARTITION: 不可能使用
ALTER TABLE ... DROP PARTITION
從NDB
資料表中刪除分割區。對於ALTER TABLE
的其他分割區擴充功能 —ADD PARTITION
、REORGANIZE PARTITION
和COALESCE PARTITION
— 支援 NDB 資料表,但是使用複製,因此沒有經過最佳化。請參閱第 26.3.1 節,「RANGE 和 LIST 分割區的管理」 和 第 15.1.9 節,「ALTER TABLE 陳述式」。分割區選擇:
NDB
資料表不支援分割區選擇。有關更多資訊,請參閱第 26.5 節,「分割區選擇」。JSON 資料類型: 在 NDB 9.0 提供的 mysqld 中,
NDB
資料表支援 MySQLJSON
資料類型。一個
NDB
資料表最多可以有 3 個JSON
欄位。NDB API 沒有針對使用
JSON
資料的特殊規定,它只是將其視為BLOB
資料。將資料處理為JSON
必須由應用程式執行。