一、明確搜尋優化的整體思路以及查詢優化的因素：
（1）搜尋優化的整體思路：
索引優化，查詢優化，查詢快取，伺服器設定優化，作業系統和硬體優化，應用層面優化（web伺服器，快取）等等。對於一個整體專案而言只有這些齊頭並進，才能實現mysql高效能。
（2）
1.是否向資料庫請求了不需要的資料：

也就是說不要輕易使用select * from ，能明確多少欄位就寫多少欄位

2.mysql是否掃描額外的紀錄：

查詢是否掃描了過多的資料。最簡單的衡量查詢開銷三個指標如下：響應時間；掃描的行數；返回的行數。

沒有哪個指標能夠完美地衡量查詢的開銷，但它們大致反映了mysql在內部執行查詢時需要多少資料，並可以推算出查詢執行的時間。

這三個指標都會記錄到mysql的慢日誌中，所以檢查慢日誌記錄是找出掃描行數過多的查詢的好辦法。

響應時間：是兩個部分之和：服務時間和排隊時間。服務時間是指資料庫處理這個查詢真正花了多長時間。 排隊時間是指伺服器因為等待某些資源而沒有真正執行查詢的時間。—可能是等io操作完成，也可能是等待行鎖，等等。

掃描的行數和返回的行數：分析查詢時，檢視該查詢掃描的行數是非常有幫助的。這在一定程度上能夠說明該查詢找到需要的資料的效率高不高。

掃描的行數和訪問型別：　在expain語句中的type列反應了訪問型別。訪問型別有很多種，從全表掃描（ALL）到索引掃描（index）到範圍掃描（）到唯一索引查詢到常數引用等。這裡列的這些，速度由慢到快，掃描的行數也是從小到大。

如果發現查詢需要掃描大量的資料但只返回少數的行，那麼通常可以嘗試下面的技巧去優化它：

使用索引覆蓋掃描。

改變庫表結構。例如使用單獨的彙總表。

重寫這個複雜的查詢。讓mysql優化器能夠以更優化的方式執行這個查詢。
三 1. 一個複雜查詢 or 多個簡單查詢

設計查詢的時候一個需要考慮的重要問題是，是否需要將一個複雜的查詢分成多個簡單的查詢。

2.切分查詢

有時候對於一個大查詢我們需要“分而治之”，將大查詢切分為小查詢，每個查詢功能完全一樣，只完成一小部分，每次只返回一小部分查詢結果。

3.分解關聯查詢

讓快取的效率更高。
將查詢分解後，執行單個查詢可以減少鎖的競爭。
在應用層做關聯，可以更容易對資料庫進行拆分，更容易做到高效能和可擴充套件。
查詢本身效率也可能會有所提升。
可以減少冗餘記錄的查詢，
更進一步，這樣做相當於在應用中實現了雜湊關聯，而不是使用mysql的巢狀迴圈關聯。

四 查詢的流程

1.客戶端傳送一條查詢給伺服器
2.伺服器先檢查查詢快取，如果命中了快取，則立刻返回儲存在快取中的結果，否則進入下一階段。
3.伺服器進行SQL解析，預處理，再由優化器生成對應的執行計劃，
4.mysql根據優化器生成的執行計劃，呼叫儲存引擎的API來執行查詢。
5.將結果返回給客戶端。
五
（1）檢視MySQL整體狀態：

1. Mysql> show status; ——顯示狀態資訊（擴充套件show status like ‘XXX’）

2. Mysql>show variables ——顯示系統變數（擴充套件show variables like ‘XXX’）

3. Mysql>show innodb status ——顯示InnoDB儲存引擎的狀態

4. Mysql>show processlist ——檢視當前SQL執行，包括執行狀態、是否鎖表等

5. Shell> mysqladmin variables -u username -p password——顯示系統變數

6. Shell> mysqladmin extended-status -u username -p password——顯示狀態資訊

7. Shell> mysqld –verbose –help [|more #逐行顯示] 檢視狀態變數及幫助；
   （2） 開啟慢日誌：
   1.如圖
   
   2 檢視日誌啟動狀態：show variables like “slow%”;
   3 設定慢日誌開啟: set global slow_query_log = ON;
   4 查詢long_query_time 的值 ：show variables like “long%”;
   也可以自己選擇修改慢查詢時間短一點