線上資料發現一條資料大量等待的現象,通過explain發現這個sql寫法存在問題,這裡簡單記錄一下.
業務場景是這樣:
存在購物車和費用兩張表,購物車資料是購買商品時生成,用於記錄購買商品資料,同時購買的商品也會生成費用表,用於統計商品總的支出情況(相當於訂單),購物車和費用的關係是多對一,通過gg_gwc.fyxh=gg_fei.id關聯.這裡需要更新滿足條件的購物車關聯的fei的資料.
因為是測試環境,實際的執行時間並不長,但是gg_fei表發現雖然使用了id索引,但是查詢條件卻是全表查詢,因為in條件中使用子查詢會造成索引失效;
這種方式實際的結果顯示是失敗的,因為它沒有從根本上改變in(子查詢)這種方式,它的想法是減少子查詢的資料,來加速sql訪問,單純從這條sql來看,實際確實也有點作用,他將子查詢8條限制為2條;但是第一條sql因為條件已經很精確,它實際的查詢只有一條;
這種方式是通過內連線查詢實現,實際查詢結果顯示有效,它將gg_fei表查詢數量降到了1條,gg_gwc也使用了索引,但是因為關聯查詢是乙個子查詢他會生成乙個派生表(簡化的臨時表),這個派生表也會增加一次查詢,雖然有效但是從表面上不是最優解.
查資料有人說:from a,b where a.id=b.id 是內連線的簡化方式,這種方式它成功的去除了子查詢,inner join也可以寫成這種方式,目前來看是這個幾個方式裡的最優解
MySQL IN 查詢優化
前幾天看到一篇博文將 in 子查詢 優化為 left join 的問題，今天自己測試測試。資料表為 test item 和 test item tag 兩個表 test item 兩個字段 item id char 36 release time int 11 共10w條記錄 test item t...
mysql in型子查詢陷阱
現在有兩個表，table1和table2，table1有1千萬資料 id 主鍵索引 table2有三條資料 uid欄位 3,5,7 select from table1 where id in select uid from table2 眨眼一看感覺這條語句應該很快 可能你會一廂情願的以為 先執行...
mysql in效能優化 MySQL 查詢效能優化
在日常開發中，程式設計師寫的最多的除了bug之外，應該算是sql語句了。sql的質量影響了程式的響應速度，只有利用mysql的特性，才能讓mysql更有效的執行查詢sql，充分發揮mysql的優勢，並避開它的弱點。為什麼查詢速度會慢?在編寫sql之前，需要清楚一點 真正重要的是響應時間。如果我們把查...