承接上期，今天繼續為大家帶來mysql視圖優化的原創專家文章分享，來自dba+社群mysql領域原創專家——李海翔。以下是第三部分的内容。
專家簡介
李海翔
網名：那海藍藍
dba+社群mysql領域原創專家
從事資料庫研發、資料庫測試與技術管理等工作10餘年，對資料庫的核心有深入研究，擅長于postgresql和mysql等開源資料庫的核心與架構。現任職于oracle公司mysql全球開發團隊，從事查詢優化技術的研究和mysql查詢優化器的開發工作。著有《資料庫查詢優化器的藝術》一書。
2 v5.7.5 視圖和from子句中的派生表的重構
2.1.1 v5.7.5 視圖和from子句中的派生表的重構内容
最近幾年，mysql的優化器進步很快，mysql的optimizer團隊對于優化器作了許多的優化工作。
mysql在5.7.5版本中，對于視圖和from子句中的derived table進行了一次重構工作，工作的結果：
1）從概念、編碼實作的角度，統一了二者的處理方式，使得相似的内容處理（視圖和派生表的處理方式）邏輯保持了一緻，同一套代碼清晰便于了解
2）提高了from子句中派生表的處理效率（對于可以merge的視圖和派生表采用merge優化）
3）對于不可merge的視圖和派生表采用“物化”的方式進行優化，達到隻執行一次多次使用的優化目的
例如：
從這個例子中可以看到，5.7.5版本中對于派生表采用了merge優化，消除了5.5中的子查詢。這樣查詢效率得到較大提高。
從編碼首先看，5.5代碼mysql_make_view()中合并（merge）優化的代碼被取出，這樣就消除了單獨優化視圖的可能。
在sql_resolve.cc檔案中通過調用select_lex::resolve_derived()統一對視圖和派生表進行了如下操作：
其中，tl可以是視圖或派生表，這樣的對象，要麼被采用“合并”的方式優化，要麼被采用“物化”的方式優化。
如下是一個物化的例子（派生表中多了一個limit子句）。
其實，mysql優化器的進化一直在進行着，有些進步盡管不如5.7.5對派生表和視圖的優化進步大，但每一個版本，總是在向前邁進。如5.6.3，物化操作隻發生在執行階段，如果是explain獲得執行計劃，則物化操作不發生。
materialization of subqueries in the from clause is postponed until their contents are needed during query execution, which improves performance。
2.1.2 v5.7.5 視圖和from子句中的派生表的重構的限制
不是所有的視圖和派生表都可以被merge，不可merge的情況，類似1.4節，即簡單視圖或派生表，可以被merge，複雜視圖和帶有group/having/distinct/limit/聚集函數等子句的派生表隻能被物化。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-11-17</b>