sql 如何加速使用 in 的查詢？

先舉個例子：
比如，過濾一些產品（衣服）顯示的時候，可以選不同的值，比如，顏色，使用者多選，紅色，綠色，藍色。
產品表，與這類的屬性工作表之間設定多對多的關係，通常一條sql語句，組合幾張表，要用到in的操作。對於這種類似的資料，聽聽大家都用什麼方案加快查詢？

看朋友們給的答案，問題太寬泛了。在具體寫一下：
方案1：
大資料量的前提下，將一些過濾條跟產品關係放在記憶體中：
將這些查詢的條件必要資料，與產品必要資料，以及關係存於redis中。這樣，每次變換過濾條件查詢時，通過redis，可以查出商品的資料集合。然後加入分頁邏輯，排序邏輯，最後取出N條資料？然後用in 或是 or，去產品表把資料載入出來？
這個可行？

看大家還有什麼更好的方案。

回複內容：

先舉個例子：
比如，過濾一些產品（衣服）顯示的時候，可以選不同的值，比如，顏色，使用者多選，紅色，綠色，藍色。
產品表，與這類的屬性工作表之間設定多對多的關係，通常一條sql語句，組合幾張表，要用到in的操作。對於這種類似的資料，聽聽大家都用什麼方案加快查詢？

看朋友們給的答案，問題太寬泛了。在具體寫一下：
方案1：
大資料量的前提下，將一些過濾條跟產品關係放在記憶體中：
將這些查詢的條件必要資料，與產品必要資料，以及關係存於redis中。這樣，每次變換過濾條件查詢時，通過redis，可以查出商品的資料集合。然後加入分頁邏輯，排序邏輯，最後取出N條資料？然後用in 或是 or，去產品表把資料載入出來？
這個可行？

看大家還有什麼更好的方案。

曾經發生的過往告訴我，遇到這種情況：

盡量不要用in做大資料集的查詢，是會死人的

希望對你有協助。

上面是模仿之前的回複，前幾天好像看到過個問題和題主類似，我的回答意思是這個例子不是幾句sql語句用一個db就能解決的，你的面已經鋪的太大了，就不要這麼小氣的設計，考慮其他的實現方式來配合db做，都交給db會吃不消的。如果真的只是考慮衣服和顏色的問題，最多也就2張表的事，小資料用in沒什麼問題，其實用or就搞定了。

曾經有一個DBA告訴我，遇到這種情況：

分表一定要合理，需要根據資料的量級精心做分表，shema最佳化，讀寫分離。
PostgreSQL 在可變長度變數的管理上要比 MySQL 好很多，而且更符合 SQL 標準。

希望對你有協助。

如果 IN 中是資料個數很少，沒問題；如果很多個，使用 JOIN 比較合適，JOIN 欄位加索引。

