關於View的使用,想確認以下幾個觀念問題:
方便示意(實際應用會複雜許多),假設資料表如下:
(依此類推,筆數可能到千萬筆)
欄位A為Index
建立一個View - View1 = select A,C from TABLE1
問題:如果使用者下的SQL為select * from View1 where A = 'A123456'
像這樣透過View方式查詢Table1,Index - A會被打中嗎?
同樣條件:View1 = select A,C from TABLE1
但是View1有建立View Index:欄位C
問題:如果使用者下的SQL為select * from View1 where C = 'C123456'
因為Table1的欄位C不是Index,所以在個情況下,建立View Index是否有幫助?
A:有幫助,因為沒有建立ViewIndex的話,Table1會Fullscan一次到記憶體,之後會再Fullscan找到C='C123456',有建ViewIndex可以加速第二段查詢效能
B:沒幫助,兩者沒有差異.
都幾?
謝謝
其實,依照你的例子來說。用view並不會比較加快。
view的使用時機,是在於將多量變少量的情況下。並可利用其view索引應用。
但如果資料表欄位常變動就不適合用view。
其實view你也可以將其視為另外一張表,它的好處就是你可以指定統計好的sql在裏面。
這樣程式碼的部份就只要呼叫這個view就好。不需要理會它是怎麼跑sql。
這是view的優點。但是,建立起來的view認真來說還是需要一段sql運做。
當view所處理的資料表有變動的情況下就會運做。
也就是說,建立view表的缺點,就是在新增或更新時。效能會比較差。
最後是我個人的見解,使用view表的時機最好是在多表結合下的語法使用。
且需確定欄位不會再變動的情況下,才去使用。
我個人是沒在用view表就是了。我個人是採用另自建表來達到像view的特性處理。
當然了,因為是另建的。所以sql碼就變成是寫在程式上處理了。且也不會因為資料變動而更新。
(雖然這就是我要的)
也就是說,建立view表的缺點,就是在新增或更新時。效能會比較差。<== 普通 view是虛的.所以這兩個操作,對view沒有影響.
也就是不針對view變動的情況下就不會有影響嘛?理論上好像也是這樣。
不過如果不變動view表資料的情況下。好像建這個view表也沒很大的意義。
不過我沒在用view。所以也不一定說的準。
View 是虛的啊, update, insert , delete 都是對 table下手,
即使是下指令對 view 做三個操作,還是到 table操作,所以沒影響的.
以前MySQL對View的處理不太好,所以就產生了不少江湖傳說.
但是世界上又不是只有MySQL,再說MySQL現在也進步很多了.
想想看,為何資料庫的廠商會花力氣去開發這功能?
其實我會這樣問,是因為很早之前我公司的工程師。曾經有用過view。
但有一次轉移主機時。他居然跟我說那個view表沒建立到。導致他的一些統計數據出不來。
再那時其實我也一直認為view是虛表。所以沒有建立表這回事。
只要其view設定在相關語法內就好。
所以我就一直再納悶這件事。
僅針對View (非Meterial View)
我們內部有不成文規定是,盡量不要在資料量很大的情況下用View(這個View可能會join多個Table)去包它,因為效能不佳。 所以才會有個疑問,把SQL包含View跟直接把SQL寫成Sub Query,是不是真的不一樣? (index會不會中? 執行計劃會變差等等)
其實我個人的見解是
一個是寫在sql內的sql碼(view)。
一個是程式寫的sql碼。
前者來說,對程式會比較方便,只要呼叫其view就行了。
(雖然我是覺得不是很方便就是了,可能我是模組控吧)
後者來說是比較直覺
但其實我是有發現到,使用mssql的人很喜歡用。
但用mysql的人員,大多數都不是很喜歡用。
(可能沒大多數人吧,至少我就不喜歡用)
盡量不要在資料量很大的情況下用View(這個View可能會join多個Table)去包它,因為效能不佳。 <== 這不是view的關係. 若是能善用MV, 可以看上面影片介紹.
關於建不建VIEW這個其實就依自已的需求及管理面來看就好。
1.VIEW僅SELECE 避免不小心下UPDATE.....等等..
2."可先事先整理出需要的欄位、條件",加速資料取得。
3.跨資料庫管理,很多時候會有共用資料時的管理,應用VIEW可以簡單達成單一TABLE同步更新之功能。