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會按規範展開，並且使用內部的格式包裹，且沒有格式化、註釋和縮進。