mysql視圖學習總結

標籤：需求   常式   解決   post   prim   選擇   schema   體會   提高   

一、使用視圖的理由是什嗎？
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視圖學習總結（轉）