- 前提:使用explain分析sql語句
例:分析左右連接查詢的sql
使用join 默認是左連接,
左邊使用的是all右使用的是eq_ref
使用left join 左邊使用的是all右使用的是eq_ref,換一種更容易理解的說法:left 左表爲驅動表(適合左表較小的情況)
使用right join 右邊使用的是all左邊使用的是all,爲什麼左邊一定是全表掃呢? 存疑
左連接,左邊表裏的數據全查出,右邊未找到對應的顯示爲null
- 可以達到優化效果的寫法和原因
mysql中:
插入數據時,對於有默認值的字段只在插入值和默認值不同時才顯式插入,避免插入時的參數校驗
避免使用sql本身的自增,因爲會涉及主鍵衝突,需要額外的保證不會衝突,影響插入效率
大量數據入庫的優化: 如果唯一約束確定唯一,或者可以容忍插入後再去除重複項,唯一約束在load file前的關閉和load後的開啓
insert優化: 批量插入減少連接消耗,多客戶端插入設置即時執行?(在內存中執行,而無需等待其他客戶端讀寫完成)
order by 優化: 使用index(表現爲explain中extra爲index而不是filesort),where條件和order by條件保持一致,多個條件order by的寫法和desc或者asc保持一致(達到重用的目的)
group by 優化: 如果不需要排序操作,可以取消默認的排序操作(order by null)
filesort 優化: 修改sort_buffer_size參數使排序儘量在內存中完成
嵌套查詢優化: 使用join代替(不需要創建臨時表?邏輯更簡潔)
or 優化: or條件都使用index(本質是按or條件查詢後做union),如何處理聯合索引(當or一邊的條件只使用了符合索引的一部分則=沒用索引;如果or一邊使用的是全部的符合索引呢?)
分頁優化: 使用index分頁後 再回表查詢
like 查詢時使用%,儘量保證左邊爲確定的字符如 ‘nam%’,減少正則匹配,正則用的不好反而是一大隱患
like優化,犧牲空間換取時間 使用全文索引使模糊查詢更快
慎用 not in 效率和易讀性,not in <not exists <join…
between 和in:當範圍爲連續的值between優於in
小表驅動大表:
① in和exists:exist外表爲驅動表(執行順序爲外表先解析,適合外表小嵌套查詢的內表大的情況),in爲in()中的查詢語句先執行,適合嵌套查詢的表小的情況
例:select x from A in(select x from B) 當B小於A時優於exists
② inner join 優於left/right join inner默認取小表驅動
where中慎用 null判斷,計算 引擎會放棄使用索引(ps:is null 和== null 不是一回事)