如果是普通的檢視，與複雜SQL的查詢區別就在於檢視減少了複雜SQL長語句的傳輸，在99.99%的情況下你是很難測出兩者的區別，或者可以說在當下這些伺服器和頻寬的狀態下，可以直接忽略這個細微的效率影響，當成一致即可。

樓上有人說到物化檢視，先說明，這個是在oracle裡面才特有的一個檢視，它是佔用物理儲存的，在MySQL裡面是沒有物化檢視等手段，但是可以通過一個簡單的轉換達到差不多的效果，MySQL可以觸發器+儲存過程去跑出一個表，這個表映射出來查詢。

其實SQL的優化要考慮比較多方面，結合起來處理才能真正消除慢SQL。

並不會，檢視只是預編譯好的查詢，可以看做一個預先編寫好的子查詢，沒有物理儲存，實際執行時是先執行檢視定義語句獲取檢視資料，再在檢視資料基礎上再次查詢，實際資料讀取上並無優化。

先說結論，不會。

原因有兩點，第一 檢視並不是獨立的儲存結構，資料還是原來的資料，查詢的時候還是要執行SQL，所以，原來的SQL慢，查詢檢視還是慢。

我們看看檢視的定義，檢視的概念VIEW （ 視 圖 ） 是 一 個 或 多 個 表 的 部 分 數 據 ， 它 可 以 像 表 一 樣 進 行 CRUD 操 作 ， 但 沒 有 具 體 的 存 儲 數 據 結 構 ， 它 以 一 個 SELECTiä 句 的 形 式 存 在 數 據 庫 中 。 本 質 ： 一 條 有 名 字 的 SELECT 語 句 表 現 ： 一 到 多 張 表 的 部 分 內 容

檢視的優點：

限制資料庫的訪問

簡化查詢

對同一資料有不同的表現

第二，複雜SQL與建立的檢視，區別僅僅是查詢時SQL從哪裡來的區別，檢視是資料庫儲存了SQL而已。

查詢過於複雜表連線過多的話是否可以將資料先加工好放入單表中再進行查詢，建好相關索引。或者可以從sql本身入手，是否有優化的地方。正常view不會對效能有影響。