长的IN子句是代码味吗？

Question

简单的问题.想知道长的IN子句是否是代码气味？我真的不知道如何证明这一点.我不能把手指放在为什么它闻起来不像我想的那样.

select
  name,
  code,
  capital,
  population,
  flower,
  bird
from us_states
where
  code in
    ('NJ', 'NY', 'PA', 'CA', 'AL', 'AK', 'AZ',
    'IL', 'IN', 'KY', 'KS', 'DC', 'MD', 'MA')

数据库通常如何实现这样的查找？是一个临时表制作并加入？或者它只是扩展为一系列逻辑OR？

感觉它应该是一个加入......

我并不是说所有的IN条款都不好.有时你无法帮助它.但是有些情况(特别是它们得到的时间越长),你所匹配的元素集实际上来自某个地方.而不应该加入呢？

是否值得创建(通过应用程序级别)一个临时表,其中包含您要搜索的所有元素,然后对其进行真正的连接？

select u.*
from us_states u

join #chosen_states t
on u.code = t.code

Answer 1

我认为这是一种代码味道.首先,数据库对子IN句中允许的元素数量有限制,如果动态生成SQL,最终可能会遇到这些限制.

当列表开始变为long-ish时,我将转换为使用带有临时表的存储过程,以避免出现任何错误.

我怀疑性能是一个主要的问题,IN条款非常快,因为它们可以短路,不像NOT IN条款.