查詢的生命週期下一步：將乙個sql轉換成乙個執行計畫，mysql再依照這個執行計畫和儲存引擎進行互動：解析sql、預處理、優化sql執行計畫
通過關鍵字將sql語句進行解析：
解析器將使用mysql語法規範驗證解析查詢，
生成解析樹，預處理器據規則檢查解析樹是否合法
優化器將語法樹從眾多執行方式中找到best的執行計畫
基於成本的優化器：**查詢使用某種執行計畫時的成本，選擇min的乙個：通過last_query_cost得當前查詢成本
show status like 'last_query_cost'策略：
靜態優化：
可直接對解析樹進行分析、完成優化；編譯時優化，第一次完成一直有效，不依賴特別的數值
動態優化：
查詢上下文相關，每次查詢重寫評估，執行時優化
能夠處理的優化型別：
重新定義關聯表的順序、將外連線轉化為內連線
等價變換規則簡化規範表示式，優化count min max （類似常量）
預估並轉化為常數表示式、覆蓋索引掃瞄、子查詢優化、提前終止查詢
等值傳播、列表in的比較：先排序、二分查詢
資料和索引的統計資訊
伺服器查詢優化器生成查詢執行計畫需向儲存引擎獲取響應的統計資訊：
每表或索引有多少個頁面，表的索引基數是多少、資料行、索引長度 、分布資訊
如何執行關聯查詢
mysql認為任何乙個查詢都是一次「關聯」，借助臨時表 關聯
執行計畫：
生成指令樹、引擎執行完成該樹返回結果
你以為是可能是這樣的
關聯查詢優化器：
決定表關聯時的順序，評估不同順序時的成本選擇，因為前面的巢狀所以這個還是挺重要的因素
當需要關聯的表數超過optimizer_search_depth限制，會選擇「貪婪」搜尋模式
排序優化:
排序過程統稱檔案排序filesort；盡可能避免排序或盡可能避免對大量資料排序
資料量《排序快取區：記憶體中快速排序；記憶體不夠，將資料分塊、每塊使用快速排序 排序，將各塊排序結果存放在磁碟上，合併 返回
排序演算法：
排序消耗臨時空間比較大：足夠長的定長空間存排序記錄、utf-8 將為每字元預留三個位元組
關聯查詢需排序：
1、order by子句all列來自關聯的第乙個表，在關聯處理第乙個表時進行檔案排序，在explain的extra欄位會有using filesort
2、其他，先將關聯結果存臨時表，all關聯結束進行檔案排序，explain的extra看到using temporary，using filesort，有limit，則limit再排序後應用
mysql5.6很多改進：
當只想要返部分排序結果，limit 不再對all結果排序，據實際情況，拋棄不滿足條件的結果再進行排序
逐步據執行計畫（乙個資料結構）完成查詢，過程中需通過儲存引擎實現的介面handler api
查詢中每張表由乙個handler例項表示(優化階段便為表建handler例項，優化器據例項介面獲取表的相關資訊）
引擎介面有豐富的功能（雖底層介面十幾個而已），儲存引擎外掛程式式架構成為可能的同時也有些限制，不是all的操作由handler完成
last階段，返回結果，可被快取將結果放到查詢快取中
增量、逐步返回的過程：
伺服器處理完最後乙個關聯表，生成第一條結果時，mysql便可開始向客戶端逐步返回結果集
好處：1、伺服器不存太多結果、記憶體省了，2、客戶端第一時間獲得返回結果
結果集每行均乙個滿足mysql客戶端/伺服器通訊協議的封包傳送 通過tcp協議傳輸 （ing封包快取批量傳輸）
該6.5了，換、誒也不知道這樣學習好不好、可能無所謂好壞吧，還有別的方法嗎？多想無益
使用新版是多麼幸福的一件事情，同時使用舊版是多麼鍛鍊人的一件事件，莫名好像知道了些什麼
話說回來，為了節省時間也是為了提高效率，部落格將縮略來寫，因為水平有限，可能總結的不是太對，所以歡迎一起交流，互相提高，嗯~先這樣。
高效能MySQL 第六章
查詢優化 索引優化 庫表結構優化 優化查詢嗎，實際上是優化其子任務。優化查詢 1。消除子任務 2。減少子任務執行次數 3。讓子任務執行的更快 查詢效能低下最基本的原因是訪問的資料太多。1 返回的結果 limit，避免返回不需要的資料 而不是返回全部結果集 select 是否需要返回全部列？2 掃瞄的...
高效能MySql學習筆記 第六章 查詢效能優化
mysql是否在掃瞄額外的記錄 切分查詢 分解關聯查詢 查詢快取 查詢優化處理 資料和索引的統計資訊 排序優化 查詢執行引擎 union的限制 並行執行 鬆散索引掃瞄 如果對優化器選擇的執行計畫不滿意，可以使用優化器提供的提示來控制最終的執行計畫。delayed straight join sql ...
第六章 查詢效能優化
如果查詢是乙個任務，那麼它由一系列子任務組成，每個子任務都會消耗時間，優化查詢其實就是優化子任務 要麼消除一些子任務 要麼減少一些子任務執行的次數 要麼加快子任務的執行速度 查詢效能低下的最基本原因就是訪問的資料太多，可以這樣分析 如果發現掃瞄了大量資料，卻只返回少量的資料行，可以這樣優化 太多的表...