1樓：Gavin Wu
哈哈，看來純mysql的優化器確實還是比較捉急的，在oracle裡，這種情況一般用in謂詞條件，然後根據in後面的引數個數做執行計畫選擇，如果較短，會走in iterator，也就是每個表記錄進行if else判斷，要是深入想一下，這就是nested join，如果in後面引數較長，就會將in後面引數組看成乙個虛擬表，然後進行hash join，大表間關聯一般都是走hash join，這種join主要消耗在構造hash bucket，所以前期準備cost比較大，所以只有大表關聯才可以容忍這種cost
2樓：慕課牛
in 型子查詢，確實在5.5之前，有該優化問題。5.6已經解決了。
5.5之前，mysql會認為是關聯查詢，將其轉換為exists，（手冊中有說）。
大神們提到的semi-join ,是 in或not in子查詢的優化方式之一，除此還應該有：物化，下推等。這個semi-join應該是上拉。
不是所有的in型子查詢，都會使用該優化方案的
3樓：
我覺得還是有這類需求的，例如乙個訂單1000個行向，每個行向需要根據商品編號查詢及時的庫存資訊，用於訂單拆分或者巡倉。
如果要在乙個事務內處理完業務邏輯，這裡的查詢還是批量的最好。
4樓：Joash
個人感覺，如果這些資料對事務的要求不高，極度贊同樓上前輩的建議redis將是不二之選。但是如果非要在mysql上搞優化的話。感覺應該重點關注兩點
1>80M資料
2>資料離散。
從中可以提煉出的資訊如下：
1>資料量很小在mysql的innodb_buffer_pool_size範圍之內
2>因為資料離散，又是80M，innodb資料庫每頁預設16k，可以粗略算一下這些資料會分發到數量多麼龐大的儲存槽中。B+樹索引這些槽需要多少次IO。無論你的SQL語句怎麼寫真正的瓶頸應該是對外存的IO操作。
建議：1>innodb_buffer_pool_size可以增加資料快取大小，但是這麼多資料會不會影響正常資料的LRU計算，導致大量有用資料無法載入到記憶體中。是不是可以配置innodb_buffer_pool_instances增加快取例項，專門快取這些資料。
沒試過不知道在不改變原始碼的基礎上這個方案可不可行。
2>正如樓上很多前輩說的80M資料很少，是不是可以考慮直接將這些資料載入進記憶體，維護乙個hashMap雜湊表。很多開源框架其核心就是乙個hashMap或者ConcurrentHashMap。如果一定要確保有序TreeMap的紅黑樹應該是可以考慮的。
3>最簡單：公升級硬碟，或者做RAID。
總之，一定要盡量避免IO瓶頸。
5樓：Super bird
我也有這個問題，delete from product where product_id in (幾千id)
速度很慢，product記錄數大概百萬條
6樓：蔣先生
剛剛測了哈 5.6 的 INNER JOIN 和 IN 發現兩個效率差不多(5000條資料, INNER JOIN快0.03秒),
然後用 EXPLAIN EXTENDED + 查詢語句 ， 再執行 SHOW WARNINGS
檢視到用 INNER JOIN 和 IN 的兩個查詢的最終sql（優化器優化後）是一樣的。
看來 IN 在新版本做了優化.
建議題主公升級到新版本.
如果不好公升級, 建議將 IN 改成 INNER JOIN
7樓：封禁讓我戒乎
沒人提到以 left join 替代 in 的做法？
先把成百上千的id插入乙個臨時表t
再 select ...
from t as a
left join 原來的表 as b on a.id=b.idwhere ...
MYSQL索引如何能提高查詢效率？
樹懶學堂 資料庫常見面試題 資料索引 B 樹索引與雜湊索引 Hash索引的優缺點 My ISAM和In no DB的使用場景 樹懶學堂索引是通過預先排列的順序，這樣在查詢時可以應用二分查詢等高效演算法。常規順序查詢，複雜性 O n 二分查詢複雜性 log2n 在n很大的情況下，兩者的效率差別及其懸殊...
mysql如何優化like 關鍵字 查詢？
kan tmac 貼個鏈結總結的不錯關於字串索引 MySQL實戰45講 李國寶 簡單來說就是 like keyword 或者like keyword 不支援 keyword one flower 為何不考慮其他方式實現呢，可以使用SQL模式匹配啊，MySQL提供標準的SQL模式匹配，以及一種基於象U...
mysql 連表查詢使用join 和 where 區別大麼？ 兩個錶用 和join連線什麼區別？
如果是inner join 沒有區別,因為優化後都是一樣的如果是left join 有區別,除非優化器可以通過邏輯優化判斷兩個表的結果是一樣的,否則兩個sql的執行是不一樣的 舉個例子 這兩個都是等於4,但是只是運氣好剛好兩個是相等的2 2 4 2 2 4 tslilove 首先我先更正一下你的問題...