1.開啟慢查詢日誌，設定超過幾秒為慢sql語句，抓取慢sq語句。l
2.通過explain檢視執行計畫，對慢sql語句分析。
3.建立索引並調整語句，再檢視執行計畫，對比優化結果。
先看type：all全表掃瞄，沒有用到索引
再看key：null沒有使用索引列
然後看rows：數值越多耗時越長
最後看extra：避免using temporary和using filesort
id:選擇識別符號，代表執行順序
select_type:表示查詢的型別。
******:簡單的select查詢，不包含聯合查詢和子查詢
primary:查詢中包含子查詢
subquery:select 或者where中包含子查詢
derived：from中包含子查詢
union：聯合查詢
union result：union後的結果集
partitions:匹配的分割槽
type:表示表的連線型別
all：全表掃瞄
index：只遍歷索引樹，索引樹上就有要查詢的結果，不需要io
range：索引範圍掃瞄
ref：非唯一性索引掃瞄
eq_ref：唯一索引掃瞄
const：通過一次索引就能查詢到，通常是primary key或者unique
system：const特例，表資料只有一行
null：不用訪問索引就可以直接查詢到結果
key：possible_key中決定使用的索引
key_len:顯示索引中使用的位元組數
ref:上述表的連線匹配條件，即哪些列或常量被用於查詢索引上的值
rows:找到所需記錄要讀取的行數
extra:
using where：僅通過索引就可以過濾所需資料
using temporary：需要使用臨時表來儲存結果集
using filesort：order by操作無法利用索引完成導致的「檔案排序」
using join buffer：連線使用了快取，可以通過新增索引來解決
using index：索引樹中包含要查詢的所有資訊
using index condition:根據輔助索引過濾資料，減少server和磁碟的io次數
適合新增索引的列：經常被查詢、經常用於表鏈結，經常排序或者分組
索引列盡量都是不重複的資料
組合索引一般不超過5列，選擇性高的放在前面
合理利用索引覆蓋，禁止select *
explain 判斷sql是否合理利用索引
單錶索引控制在5個以內
不建議在頻繁更新的字段上新增索引
where條件中的索引列不能是表示式的一部分，避免對索引列進行函式計算
join型別的字段必須型別一致且都建立索引
隱式的型別轉換會導致索引失效，導致全表掃瞄
對索引列進行函式或者數學計算，例如日期格式化
模糊匹配未使用字首匹配
使用了負方向查詢，not，!=，not in等
按需查詢避免 select *
無法使用覆蓋索引，回表，增加io
多查詢的列，會有多餘的io和網路開銷
避免大事務，將大事務拆成小事務。防止出現鎖阻塞，導致的雪崩效應
少用多表join，禁止大表join，小表驅動大表，join列必須字符集一致，且有索引
盡量避免多層子查詢巢狀
定期對慢sql優化
慢SQL優化 索引優化
在專案開發的時候難免會寫一些sql語句，剛開始資料量比較小或沒預料到資料的增長速度很快，在後期的維護中偶爾會有慢sql出現，嚴重的會影響到線上服務正常執行和使用者體驗。當然慢sql的優化角度有多種，比如增 減索引 調整搜尋條件的順序 優化查詢結果引數 分庫分表 讀寫分離等等，但本篇我們主要談一下索引...
SQL慢查詢優化
3月19日，3月20日的18 00 20 00之間，db伺服器的cpu load飆公升 dba提出問題原因是sql where rest id and state and id and valid 掃瞄行數太多，執行時間過長 在b端心跳連線時，會傳 queue marker 引數，含義為上次處理的最...
sql查詢慢優化
select g.goods id,g.type id,g.user id,g.productname,g.img,g.intro,g.attr,u.companyname,u.enloginname,u.userid from site goods g force,ucenter member u...