一、使用視圖的理由是什么？
1.安全性。一般是這樣做的:創建一個視圖，定義好該視圖所操作的數據。之后將用戶權限與視圖綁定。這樣的方式是使用到

了一個特性：grant語句可以針對視圖進行授予權限。
2.查詢性能提高。

3.有靈活性的功能需求后，需要改動表的結構而導致工作量比較大。那么可以使用虛擬表的形式達到少修改的效果。

這是在實際開發中比較有用的

例子：假如因為某種需要，a表與b表需要進行合并起來組成一個新的表c。最后a表與b表都不會存在了。而由于原來程序中編

寫sql分別是基于a表與b表查詢的，這就意味著需要重新編寫大量的sql(改成向c表去操作數據)。而通過視圖就可以做到不修

改。定義兩個視圖名字還是原來的表名a和b。a、b視圖完成從c表中取出內容。

說明：使用這樣的解決方式，基于對視圖的細節了解越詳細越好。因為使用視圖還是與使用表的語法上沒區別。比如視圖名a
，那么查詢還是"select * from a"。

4.復雜的查詢需求。可以進行問題分解，然后將創建多個視圖獲取數據。將視圖聯合起來就能得到需要的結果了。



視圖的工作機制:當調用視圖的時候，才會執行視圖中的sql，進行取數據操作。視圖的內容沒有存儲，而是在視圖被引用的時候才派生出數據。這樣不會占用空間，由于是即時引用，視圖的內容總是與真實表的內容是一致的。

視圖這樣設計有什么好處？節省空間，內容是總是一致的話，那么我們不需要維護視圖的內容，維護好真實表的內容，就可以保證視圖的完整性了。

二、通過更新視圖實現更新真實表

看到很多例子，更新視圖可以更新真實表。原因，我是這樣理解的：視圖并沒有保存內容。只是引用數據。那么，更新視圖，其實就是以引用的方式操作了真實表
with check option：對視圖進行更新操作的時，需要檢查更新后的值是否還是滿足視圖公式定義的條件。通俗點，就是所更新的結果是否還會在視圖中存在。如果更新后的值不在視圖范圍內，就不允許更新如果創建視圖的時候，沒有加上with check option，更新視圖中的某項數據的話，mysql并不會進行有效性檢查。刪掉了就刪掉了。在視圖中將看不到了。


使用有效性檢查，實際意義是什么？


視圖的實踐：重新組織表的需求
CREATE TABLE `result` (`MATH_NO` INT(10) NOT NULL unsigned AUTO_INCREMENT PRIMARY KEY,
`TEAMNO` INT(10) NOT NULL,
`PLAYERNO` INT(10) NOT NULL,
`WON` VARCHAR(10) NOT NULL,
`LOST` VARCAHR(10) NOT NULL,
`CAPTAIN` INT(10) NOT NULL COMMIT '就是PLAYERNO的另外名字',
`DIVISION` VARCHAR(10) NOT NULL
) ENGINE=MYISAM? DEFAULT CHARSET=utf8 COMMIT='重新組的新表' AUTO_INCREMENT=1


針對每個表創建一個視圖，將數據保存進去：
CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION) AS SELECT? DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result

報錯：#1050 - Table 'teams' already exists

說明，因為視圖也是一種表，是虛擬表。不能與已有的表(視圖)出現重名

接下來，刪掉表teams，再執行創建視圖的代碼。


將視圖看成與表一樣的東西，更加容易理解使用規則。下面這樣對比也許使自己更好理解：

1.在使用視圖的時候，就是與使用表的語法一樣的。
2.創建視圖的時候，該視圖的名字如果與已經存在表重名的話，那么會報錯，不允許創建。視圖就是一種特殊的表

3.創建視圖的時候，可以這樣使用CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION)，可以定義視圖表的結構。
4.在phpmyadmin中。左邊的表列表中將視圖與表列在了一起。只有通過右側的狀態"View:teams"可以知道該表是視圖表。



視圖在mysql中的內部管理機制:

視圖的記錄都保存在information_schema數據庫中的一個叫views的表中。具體某個視圖的定義代碼以及屬于哪個數據庫等信息可以從里面看到理解視圖的兩種工作機制：

語句：select * from teams

針對上面語句，總結幾個知識點
1.確認是視圖的過程：teams也可以是表名。由于表與視圖的物理機制不同。視圖本身是不存儲內容的。所以，在使用sql的
時候，mysql是怎么知道teams是一個視圖還是表。是因為有一個查看目錄的例程在做這件事。

2.mysql對處理視圖的兩種方法：替代方式和具體化方式。
替換方式理解，視圖名直接使用視圖的公式替換掉了。針對上面視圖teams，mysql會使用該視圖的公式進行替換，視圖公式合并到了select中。結果就是變成了如下sql語句：
select * from (SELECT? DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result)。也就是最后提交給mysql處理該sql語句。


具體化方式理解，mysql先得到了視圖執行的結果，該結果形成一個中間結果暫時存在內存中。之后，外面的select語句就調

用了這些中間結果(臨時表)。


看起來都是要得到結果，形式上有區別，好像沒體會到本質上的區別。兩種方式又有什么樣的不同呢？

替換方式，將視圖公式替換后，當成一個整體sql進行處理了。具體化方式，先處理視圖結果，后處理外面的查詢需求。
替換方式可以總結為，先準備，后執行。
具體化方式總結理解為，分開處理。

哪種方式好？不知道。mysql會自己確定使用哪種方式進行處理的。自己在定義視圖的時候也可以指定使用何種方式。像這樣

使用：

CREATE ALGORITHM=merge VIEW teams as SELECT? DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result

ALGORITHM有三個參數分別是：merge、TEMPTABLE、UNDEFINED

看mysql手冊中提到，替換與具體化的方式的各自適用之處，可以這樣理解：
因為臨時表中的數據不可更新。所以，如果使用參數是TEMPTABLE，無法進行更新。
當你的參數定義是UNDEFINED(沒有定義ALGORITHM參數)。mysql更傾向于選擇合并方式。是因為它更加有效。

mysql視圖學習總結