響應時間過長。如果把查詢看做是乙個任務，那麼它由一系列子任務組成，每個子任務都會消耗一定的時間。如果要優化查詢，實際上優化其子任務，要麼消除其中一些子任務，要麼減少子任務的執行次數，要麼讓子任務執行得更快。
查詢的生命週期:
客戶端->伺服器->伺服器上解析->生成執行計畫->執行->返回結果給客戶端。
其中」執行」包括大量為了檢索資料到儲存引擎的呼叫以及呼叫後的資料處理，包括排序、分組等。
查詢效能低下最基本的原因:訪問的資料太多。
低效查詢分析:
1.確認應用程式是否在檢索大量超過需要的資料;
2.確認mysql伺服器層是否在分析大量超過需要的資料行;
典型案例(主要體現為了省事，使用select *):
在確定查詢只返回需要的資料以後，接下來看查詢為了返回結果是否掃瞄過多的資料。對於mysql,最簡單的衡量查詢開銷的三個指標:
響應時間
響應時間包含服務時間和排隊時間。
服務時間是指資料庫處理這個查詢真正花了多長時間。
排隊時間是指伺服器因為等待某些資源而沒有真正執行查詢的時間，可能等i/o操作完成，也可能等待行鎖。
掃瞄的行數和返回的列數
在一定程度上能夠說明該查詢找出需要的資料的效率高不高。
理想情況下掃瞄行數和返回的行數應該是相同的。
掃瞄的行數和訪問型別
訪問型別主要指全表掃瞄、索引掃瞄、範圍掃瞄、唯一索引查詢、常數引用。
一般mysql能夠使用如下三種方式應用where條件，從好到壞依次為:
如果發現查詢需要掃瞄大量的資料但只返回少數的行，那麼通常可以嘗試下面的技巧去優化它:
複雜查詢拆分多個簡單查詢
切分查詢
將大查詢拆分為小查詢，每個查詢功能完全一樣，只完成一小部分，每次只返回一小部分查詢結果。
分解關聯查詢
用分解關聯查詢的方式重構查詢有如下優勢:
2.伺服器先檢查查詢快取，如果命中快取，則立刻返回儲存在快取中的結果。否則進入下一階段。
3.伺服器端進行sql解析、預處理，再由優化器生成對應的執行計畫。
4.mysql根據優化器生成的執行計畫，呼叫儲存引擎的api來執行查詢。
5.將結果返回給客戶端。
優化count()查詢
優化關聯查詢
優化子查詢
對於子查詢的優化，盡可能使用關聯查詢代替。
優化group by 和 order by
最有效的優化辦法是使用索引。
當無法使用索引時，可以使用臨時表或者檔案排序來做分組。
另外如果需要對關聯查詢做分組，並且是按照查詢表中的某個列進行分組，那麼通常採用查詢表的標識列分組的效率會比其他列更高。
優化limit 分頁
在系統中需要進行分頁操作的時候，我們通常會使用limit 加上偏移量的辦法實現，同時加上合適的order by子句。如果有對應的索引，通常效率會不錯，否則，mysql需要做大量的檔案排序操作。
優化union查詢
靜態查詢分析
使用使用者自定義變數
那些場景不能使用使用者自定義變數:
使用者自定義變數的用法:
高效能mysql 樹 高效能mysql精要
1 explain 中 extra using index 表示覆蓋索引，sql優化中最好能使用覆蓋索引，否則 二級索引 需要回表查詢。所謂覆蓋索引，是指要查詢的列正好是索引，而條件也是這個索引之一 2 where 語句中 條件等於主鍵的 在核心索引層完成，條件等於非索引的，在服務層完成 3 讀索引...
mysql高效能索引 mysql高效能索引（ ）
在開發中，我們知道大多數應用的瓶頸在於sql語句的執行時耗，在這裡並不討論sql語句的安全，僅僅討論高效能sql語句，而與高效能sql語句緊密相連的就是傳說中的 索引。索引 一種工作在儲存引擎端的用於快速找到記錄的一種資料結構。mysql使用索引的方式是 先找到索引的值，再根據索引的值找到資料行。索...
高效能MySql之併發控制
剛買了一本高效能mysql這本書，順便做個筆記記錄學習的足跡。一 共享鎖和排它鎖 mysql的鎖系統 shared lock和exclusive lock 共享鎖和排他鎖，也叫讀鎖和寫鎖，即write lock和read lock 讀鎖是共享的，或者說是相互不阻塞的 寫鎖是排他的，乙個寫鎖會阻塞其他...