在檢視表的定義中可以參照的最大資料表數為 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 陳述式。但是,這不會變更原始檢視表定義,這可能會導致後續傾印操作發生問題。