热搜:NVER 

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

2024-04-29 18:39:01
 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进行批量处理吗?


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