在檢視表的定義中可以參照的最大資料表數為 61 個。
檢視表處理未經最佳化
無法在檢視表上建立索引。
索引可用於使用合併演算法處理的檢視表。但是,使用臨時表演算法處理的檢視表無法利用其基礎資料表上的索引(儘管索引可用於產生臨時資料表期間)。
有一個一般原則,您無法在子查詢中修改資料表並從同一個資料表選取。請參閱第 15.2.15.12 節,「子查詢的限制」。
如果從檢視表中選取資料,而該檢視表是從該資料表中選取的,如果檢視表是從子查詢中的資料表選取資料,並且使用合併演算法評估檢視表,則同樣的原則也適用。範例
CREATE VIEW v1 AS
SELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE t1.a = t2.a);
UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;
如果使用臨時資料表評估檢視表,則可以從檢視表子查詢中的資料表選取資料,並且仍然可以在外部查詢中修改該資料表。在這種情況下,檢視表會儲存在臨時資料表中,因此您並不是真的在子查詢中從資料表中選取資料,同時又修改它。(這是您可能希望強制 MySQL 使用臨時表演算法的另一個原因,方法是在檢視表定義中指定 ALGORITHM = TEMPTABLE
)。
您可以使用 DROP TABLE
或 ALTER TABLE
來刪除或變更檢視表定義中使用的資料表。DROP
或 ALTER
操作不會產生任何警告,即使這樣會使檢視表失效。相反地,當使用檢視表時,稍後會發生錯誤。CHECK TABLE
可用於檢查因 DROP
或 ALTER
操作而失效的檢視表。
關於檢視表的可更新性,檢視表的總體目標是,如果任何檢視表在理論上是可更新的,則實際上應該是可更新的。許多在理論上可更新的檢視表現在可以更新,但仍然存在限制。有關詳細資訊,請參閱第 27.6.3 節,「可更新和可插入的檢視表」。
目前檢視表的實作存在一個缺點。如果授予使用者建立檢視表所需的基本權限(CREATE VIEW
和 SELECT
權限),除非使用者也獲得 SHOW VIEW
權限,否則該使用者無法在該物件上呼叫 SHOW CREATE VIEW
。
該缺點可能會導致使用 mysqldump 備份資料庫時發生問題,這可能會因為權限不足而失敗。此問題在錯誤 #22062 中描述。
該問題的解決方法是,管理員手動將 SHOW VIEW
權限授予獲得 CREATE VIEW
權限的使用者,因為 MySQL 在建立檢視表時不會隱含地授予該權限。
檢視表沒有索引,因此索引提示不適用。從檢視表中選取時不允許使用索引提示。
SHOW CREATE VIEW
使用每個資料行的 AS
子句顯示檢視表定義。如果資料行是從運算式建立的,則預設別名是運算式文字,這可能會很長。別名
CREATE VIEW
陳述式中資料行名稱的別名會針對最大資料行長度 64 個字元(而不是最大別名長度 256 個字元)進行檢查。因此,如果任何資料行別名超過 64 個字元,則從 SHOW CREATE VIEW
的輸出建立的檢視表會失敗。這可能會在下列情況下導致具有過長別名的檢視表發生問題
檢視表定義無法複製到強制執行資料行長度限制的較新複本。
使用 mysqldump 建立的傾印檔案無法載入到強制執行資料行長度限制的伺服器。
解決上述任一問題的方法是修改每個有問題的檢視表定義,以使用提供較短資料行名稱的別名。然後檢視表就會正確複製,並且可以傾印和重新載入而不會導致錯誤。若要修改定義,請使用 DROP VIEW
和 CREATE VIEW
再次刪除並建立檢視表,或使用 CREATE OR REPLACE VIEW
取代定義。
針對重新載入傾印檔案中的檢視表定義時發生的問題,另一個解決方法是編輯傾印檔案以修改其 CREATE VIEW
陳述式。但是,這不會變更原始檢視表定義,這可能會導致後續傾印操作發生問題。