看了下面各位的回答，有的說用exist，有的說用join，難道你們不是在把簡單的事情復(fù)雜化了嗎？竟然還有子表子查詢一說？也有朋友說的很精準(zhǔn)，不要用select *，這個*是個坑，實際開發(fā)過程中，關(guān)于MySQL開發(fā)規(guī)范也會明確告知大家不要select *。
首先我想問的是：查詢MySQL的一張表怎么查最快？當(dāng)然是根據(jù)主鍵查詢了！
默認(rèn)你的MySQL庫、表引擎是Innodb引擎，然后會有一顆主鍵的B+樹，葉子節(jié)點就是這個主鍵索引對應(yīng)的數(shù)據(jù)，意味著一次查詢即可，回表都不需要好不好？簡單直接！
這就是MySQL在Innodb引擎下的聚集索引。
什么是聚集索引？InnoDB聚集索引的葉子節(jié)點存儲行記錄，因此InnoDB必須要有且只有一個聚集索引。
1.如果表定義了PK（Primary Key，主鍵），那么PK就是聚集索引。
2.如果表沒有定義PK，則第一個NOT NULL UNIQUE的列就是聚集索引。
3.否則InnoDB會另外創(chuàng)建一個隱藏的ROWID作為聚集索引。
這種機制使得基于PK的查詢速度非常快，因為直接定位的行記錄。
下圖是利用普通索引做查詢時候的一個回表操作，如何避免回表操作？使用覆蓋索引！即select xxx,yyy from table where xxx='' and yyy=''，只能查詢xxx,yyy就會避免回表操作！
所以你還搞什么其他各種操作來秀呢？只不過題主說了id不是連續(xù)的，所以做不到范圍查詢，也就無法between查詢了。
不要純粹的依賴數(shù)據(jù)庫如果這個查詢量級很大，并發(fā)很高，原則上我們是不允許直接查庫的，中間必須有一層緩存，比如Redis。那至于這個數(shù)據(jù)怎么存儲到redis就要看具體業(yè)務(wù)具體分析了。
如果內(nèi)存足夠，甚至可以把這幾十萬的數(shù)據(jù)直接放到redis里面去，然后通過redis 的管道查詢一次給批量查詢出來。
如果沒必要存儲這么多，或者不讓存這么多，是不是可以采用redis的淘汰策略來控制緩存里的數(shù)據(jù)都是熱點數(shù)據(jù)？