Sql查詢優化
如何獲取有性能問題的SQL
通過用戶反饋獲取存在性能問題的SQL
通過慢查日誌獲取存在性能問題的SQL
實時獲取存在性能問題的SQL
慢查詢日誌：主要開銷爲磁盤IO和存儲日誌所需要的磁盤空間、存儲日誌要佔據很大的內存
·slow_query_log 是否開啓慢查詢日誌
·slow_query_log_file 指定慢查詢日誌的存儲路徑及文件
日誌存儲和數據存儲是分開存儲的
·slow_query_time 指定記錄慢查詢日誌SQL執行的時間的伐值、
·slow_queries_not_using_indexes 是否記錄未使用索引的SQL
慢查詢日誌中記錄的內容：
1.用戶信息
2.SQL執行的時間
3.鎖的時間
4.SQL返回的數據行數
5.SQL掃描數據的的行數
6.以時間戳形式展示SQL執行的時間
7.執行的SQL
慢查詢日誌在很短的時間內就會生成大量的日誌。因此人爲的去檢查慢查詢日誌是不現實的，所以我們必須要藉助工具
常用的慢查詢日誌分析工具：
·mysqldumpslow
·pt-query-digest
通過慢查日誌獲取存在性能問題:
Information_schema數據庫下水位processlist表
爲什麼查詢會比較慢？
SQL的解析預處理及生成執行計劃–SQL處理查詢請求的整個過程
·客戶端發送SQL請求給服務器
·服務器檢查是否可以在查詢緩存中命中該SQL
如果查詢緩存是打開的：
1.優先檢查這個查詢是否命中查詢緩存中的數據–通過一個對大小寫敏感的hash查找實現的—hash查找只能進行全值匹配
2.檢查用戶權限，如何符合調劑而直接從緩存中拿到結果
如果查詢緩存未啓用或者未命中-----mysql依照這個執行計劃和存儲引擎進行交互
·服務器端進行SQL解析，預處理，在由優化器生成隊形的執行計劃
·根據執行計劃，調用存儲引擎API來查詢數據
·將結果返回給客戶端
會造成mysql生成錯誤的執行計劃的原因
·統計信息不準確
·執行計劃中的成本估算不等與實際的執行計劃的成本
Mysql服務器層並不知道那些頁面在內存中
那些頁面在磁盤上 那些需要順序讀取
那些頁面需要隨機讀取
·mysql優化器所認爲的最優可能與你所認爲的最優不一樣
·mysql從不會考慮併發的查詢，這可能影響當前的查詢速度
·mysql有時候也會基於一些固定的規則來生成一些執行計劃
·mysql不會考慮不受其控制的成本，存儲過程，用戶自定義的函數
Mysql優化器可優化的SQL類型：
·重新定義表的關聯順序
優化器會根據統計信息來決定表的關聯順序
·將外連接轉化成內連接
where條件和庫表結構等
·使用等價變化
·優化count(),min(),max()
select tables optimized away
優化器已經從執行計劃中移除了該表，並以一個常數取而代之
·將一個表達式轉化爲常數表達式
·使用等價變化原則
·子查詢進行優化
·提前終止查詢
·對in()條件進行優化