sql话语中当条件的数量非常大时where.in条件子句用什么更好的方法代替

sql语句中当条件的数量非常大时where...in条件子句用什么更好的方法代替？
当sql语句中的where条件是where id in(1,2,3,4,8,11,23,56,89,110,...)，即当in的数量相当大时，这种sql语句是很劣质的，那么用什么其它更好的方法解决这样的问题呢？

------解决方案--------------------
把in中的id分开来查询，最后再合并起来。
------解决方案--------------------
select * from x where id=1 union all select * from x where id=2 union all ...
------解决方案--------------------
这个就不错了。
------解决方案--------------------
能告诉我你列表中的id是怎么来的吗？
------解决方案--------------------
那就不是 sql语句很劣质的 的问题了，既然你允许传入一万个 id 值，那么为什么要说包含这一万个 id 值得 in 子句是劣质的呢？
------解决方案--------------------
那么你认为把传入的 id 组先存入表，然后再关联查询是否更明智呢？
------解决方案--------------------
或者是遍历传入的 id 组，在循环里逐一查询，更明智点？
------解决方案--------------------

探讨

或者是遍历传入的 id 组，在循环里逐一查询，更明智点？

------解决方案--------------------
有兴趣的话可以看这个blog
http://explainextended.com/2009/08/18/passing-parameters-in-mysql-in-list-vs-temporary-table/

不过,就如blog结尾所说,只有在数量比较大的情况下才能看出明显效果. 


如果你的id就那么几个,几十个...我不认为需要考虑这点差别.

1,2楼分开查询的方法我认为不可取, 因为mysql内部的处理大概也不会比那样更差吧...

探讨

当sql语句中的where条件是where id in(1,2,3,4,8,11,23,56,89,110,...)，即当in的数量相当大时，这种sql语句是很劣质的，那么用什么其它更好的方法解决这样的问题呢？

------解决方案--------------------
同意楼上，仅几个,几十个(甚至几百个)的 IN ID 效率低不到哪去。不然你还有什么好办法。
------解决方案--------------------

探讨

同意楼上，仅几个,几十个(甚至几百个)的 IN ID 效率低不到哪去。不然你还有什么好办法。

------解决方案--------------------

探讨

能告诉我你列表中的id是怎么来的吗？

------解决方案--------------------

探讨

引用:
能告诉我你列表中的id是怎么来的吗？

我觉得这才是问题的要点。如果可能的话，把当初获得这一组id的sql语句跟后面要实现的sql语句结合起来做关联查询。

如果这一组id不是用某个sql语句得到的，那恐怕要重新考察一下业务需求和实现方案了，真的需要对这么大的一组“没来由”的id进行批量处理吗？


―――――――――――――――――――――――――――……

------解决方案--------------------

探讨

没测试过，你的意思是联合查询比where in 更好？

------解决方案--------------------
嘿嘿, 没看我上面贴的blog吧...那是插入临时表再join查询...数据大的情况比in快.

探讨

引用:

引用:
能告诉我你列表中的id是怎么来的吗？

我觉得这才是问题的要点。如果可能的话，把当初获得这一组id的sql语句跟后面要实现的sql语句结合起来做关联查询。

如果这一组id不是用某个sql语句得到的，那恐怕要重新考察一下业务需求和实现方案了，真的需要对这么大的一组“没来由”的id进行批量处理吗？


――――――――――……