看了下面各位的回答，有的說用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的查詢速度非?？欤驗橹苯佣ㄎ坏男杏涗?。

下圖是利用普通索引做查詢時候的一個回表操作，如何避免回表操作？使用覆蓋索引！即select xxx,yyy from table where xxx='' and yyy=''，只能查詢xxx,yyy就會避免回表操作！

所以你還搞什么其他各種操作來秀呢？只不過題主說了id不是連續的，所以做不到范圍查詢，也就無法between查詢了。

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

如果內存足夠，甚至可以把這幾十萬的數據直接放到redis里面去，然后通過redis 的管道查詢一次給批量查詢出來。

如果沒必要存儲這么多，或者不讓存這么多，是不是可以采用redis的淘汰策略來控制緩存里的數據都是熱點數據？