MySQL 5.0以后引入了視圖。視圖實際是一個自身不存儲數據的虛擬數據表。實際這個虛擬表的數據來自于訪問視圖的 SQL 查詢的結果。MySQL 處理視圖和處理數據表差不多，通過這種方式來滿足很多需求。視圖和數據表在 MySQL 中共享命名空間，然而 ，MySQL 處理而二者的方式并不相同，例如，視圖沒有觸發器，并且無法使用 DROP TABLE 移除視圖。

下面以 world 樣例數據庫為例來展示視圖的工作機制。

CREATE VIEW Oceania AS
	SELECT * FROM Country WHERE Continent = 'Oceania'
  WITH CHECK OPTION;

實現視圖最簡單的方式是執行SELECT查詢語句并將結果放入到一張臨時表中。之后，就可以在視圖出現的地方引用這張臨時表。例如下面的查詢語句：

SELECT Code, Name FROM Oceania WHERE Name = 'Australia';

下面是服務端執行上面語句可能的形式（臨時表名稱是隨意取的，實際內部不知道是什么）：

CREATE TEMPORARY TABLE TMP_Oceania_123 AS 
	SELECT * FROM Country WHERE Continent = 'Oceania';
SELECT Code, Name FROM TMP_Oceania_123 WHERE NAME = 'Australia';

這種形式顯然存在性能問題，最好的方式是將視圖和查詢的分布查詢改為一句 SQL 語句，如下所示：

SELECT Code, Name FROM Country
WHERE Continent = 'Oceania' AND Name = 'Australia';

在 MySQL 中會使用兩種算法，稱之為 MERGE 和 TEMTABLE，而且會盡可能地使用 MERGE 算法。甚至，MySQL 能夠將嵌套視圖進行合并。下圖是兩種算法的區別：

當視圖中有 GROUP BY，DISTINCT，聚集函數，UNION，子查詢或其他數據表之間不是一對一的關系時，MySQL 會使用 TEMPTABLE算法。如果想知道視圖是使用 MERGE 還是 TEMPTABLE，可以使用 EXPLAIN 指令檢查：

EXPLAIN SELECT * FROM 視圖名稱>;

如果在 select_type 中有 DERIVED 的話，則表示使用了 TEMPTABLE 算法。因此，如果隱藏的衍生表需要很高的代價產生，EXPLAIN 就會變得性能很低并且執行起來很慢，這是因為它需要實際執行和構建衍生表。這個算法是視圖的屬性而不會受到查詢類型的影響。例如，假設創建視圖的時候指定了算法，那么以后針對這個視圖的查詢都不會更改算法，即便有優化的空間：

CREATE ALGORITHM=TEMPTABLE VIEW v1 AS
SELECT * FROM Country;

可更新視圖

可更新視圖可以通過視圖更新隱藏的基礎表，只要指定的條件保持，就可以使用 UPDATE，DELETE 甚至是 INSERT 操作，就像操作普通表一樣，例如下面的操作是有效的：

UPDATE Oceania SET Population = Population * 1.1 WHERE NAME = 'Australia';

如果視圖包括 GROUP BY，UNION，聚合函數或其他的一些概念，那么該視圖就不可更新。所有使用了 TEMPTABLE 算法的視圖都不可以更新。

CHECK OPTION 子句用于保證任何通過視圖更改的數據行在更改后需要保持與視圖的 WHERE條件匹配。例如上面的例子，如果插入了一條 Continent 值不同的行，服務端就會報錯。

視圖的性能

很多人不會考慮使用視圖提升性能，但是在某些情況下視圖是可以提高性能的。而且還可以用視圖去提升其他方面的性能，例如，在表結構重構時，被修改的數據表的視圖不經修改也可以使用。還可以使用視圖實現字段權限控制而不增加創建列權限的負荷：

CREATE VIEW public.employeeinfo AS
	SELECT firstname, lastname  --不包含身份證號
  FROM private.employeeinfo;
GRANT SELECT ON public.* to public_user;

使用 TEMPTABLE 算法的視圖性能可能很糟糕（雖然也有可能比等效的 SQL 查詢性能高）。這種視圖可優化的空間不高。

視圖可能讓開發者誤以為視圖很簡單，而事實上視圖非常復雜。如果開發者不懂的試圖的復雜性，那么就不會注意到視圖與普通表查詢之間的差別。如果使用EXPLAIN 指令的話有時候會發現產生上百行的分析結果輸出，這是因為實際看起來是數據表的查詢實際是視圖，而視圖可能引用其他數據表甚至是其他視圖。

在使用視圖改進性能時，需要仔細分析和測試。即便是 MERGE 算法的視圖也會增加額外的負擔，而且很難預測對性能的影響。視圖實際在 MySQL 中使用了另外的優化途徑。在高并發場景，視圖可能導致查詢優化器耗費大量時間在做計劃和統計，甚至導致服務端卡頓。這個時候需要使用普通的 SQL 來替代視圖。

視圖的限制

MySQL 不像其他數據庫服務器那樣支持物理視圖（物理視圖即產生并將結果存在一個不可見的數據表中，并周期性地更新以從源數據刷新視圖）。MySQL 也不支持視圖的索引。MySQL 也不會保留視圖的原始 SQL，如果我們視圖通過執行 SHOW CREATE VIEW 指令去編輯視圖，并且更改返回結果 SQL，會發現結果很奇特。查詢SQL會按規范展開，并且使用內部的格式包裹，且沒有格式化、注釋和縮進。

以上就是MySQL 視圖（View）原理解析的詳細內容，更多關于MySQL 視圖（View）原理的資料請關注腳本之家其它相關文章！