看了下面各位的回答，有的說用exist，有的說用join，難道你們不是在把簡單的事情複雜化了嗎？竟然還有子表子查詢一說？也有朋友說的很精準，不要用select *，這個*是個坑，實際開發過程中，關於MySQL開發規範也會明確告知大家不要select *。

首先我想問的是：查詢MySQL的一張表怎麼查最快？當然是根據主鍵查詢了！

預設你的MySQL庫、表引擎是Innodb引擎，然後會有一顆主鍵的B+樹，葉子節點就是這個主鍵索引對應的資料，意味著一次查詢即可，回表都不需要好不好？簡單直接！

這就是MySQL在Innodb引擎下的聚集索引。

InnoDB聚集索引的葉子節點儲存行記錄，因此InnoDB必須要有且只有一個聚集索引。

1.如果表定義了PK（Primary Key，主鍵），那麼PK就是聚集索引。

2.如果表沒有定義PK，則第一個NOT NULL UNIQUE的列就是聚集索引。

3.否則InnoDB會另外建立一個隱藏的ROWID作為聚集索引。

這種機制使得基於PK的查詢速度非常快，因為直接定位的行記錄。

如果這個查詢量級很大，併發很高，原則上我們是不允許直接查庫的，中間必須有一層快取，比如Redis。那至於這個資料怎麼儲存到redis就要看具體業務具體分析了。

如果記憶體足夠，甚至可以把這幾十萬的資料直接放到redis裡面去，然後通過redis 的管道查詢一次給批量查詢出來。

如果沒必要儲存這麼多，或者不讓存這麼多，是不是可以採用redis的淘汰策略來控制快取裡的資料都是熱點資料？

一，幾萬幾十萬的資料量，ID查詢速度應該還是可以的。二，如果只是為了查詢幾個關鍵字，可以不用select* ，使用能命中組合索引的欄位組.三，基礎表資料量很大的話，建議分表操作.以上，謝謝！

我只建議把*換成對應的列名！mysql對in的查詢也是走索引的！而mysql的索引id實際上是帶有id對應行的所有資料！所以，in幾百或幾千可以不處理直接查

幾十萬行，in還有幾百上千，應該還有一層關係，按歸類給id做排序索引，使得你要的是其中幾段：也即，隨機io轉連續io，再加索引覆蓋。

mysql8.0版本中有with公共表示式，這個是最好的，通過兩個表做關聯，8.0以下的取決於你的where條件了，icp可以謂詞下推，in在優化器會自動轉換成semi-jion，在8.0.4以後exists也可以使用semi join了，在之前的時候exists就只能使用dependent subquey了，exists 要想快的話是 小表驅動大表；所以說這裡最重要的是看你的where條件中是否有篩選。如果沒有的話，最好建臨時表 或者用with，另外不要用select *，要不然在後面優化器 需要block nestloop的時候會有壓力，如果都不讓用的話，你目前的敘述，in比exists好

不知道你所謂的提高效率是什麼意義，如果說的是效能，幾百個，幾千個用in感覺不出效能差異的，後面加個萬才會有感覺，當然用in的效率遠遠低於exists

MySQL官網有對in的說法，如果有索引，其實都差不多。如果你查詢的不是所有欄位，只拿abc三個欄位，可以在abc三個欄位建立組合索引，in再走索引。如果我沒有記錯MySQL不會限制你in多少，但是會限制整個SQL總位元組數

1，去掉*, select table.name,table.age,table.asscess from table where in ( ....)

2.如果id是連續的範圍，那就用between and 代替in

select a.* from tableA a

inner join （select id from tableB）b on a. id=b. id

建立臨時表tableB並建主鍵索引，

或者構建inner join的只包括id欄位的虛擬表b。