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 字段加索引。