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

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

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

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

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

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

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 能夠將嵌套視圖進行合并。下圖是兩種算法的區(qū)別：

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

EXPLAIN SELECT * FROM 視圖名稱>;

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

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，聚合函數(shù)或其他的一些概念，那么該視圖就不可更新。所有使用了 TEMPTABLE 算法的視圖都不可以更新。

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

視圖的性能

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

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

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

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

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

視圖的限制

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

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