对于这样数量可变的参数，我所知道的唯一方法是显式地生成SQL，或者做一些涉及用所需项填充临时表并与临时表连接的事情。

唯一的制胜方法就是不玩。

对你来说没有无限的可变性。只有有限的可变性。

在SQL中，你有这样一个子句:

and ( {1}==0 or b.CompanyId in ({2},{3},{4},{5},{6}) )

在c#代码中，你可以这样做:

  int origCount = idList.Count;
  if (origCount > 5) {
    throw new Exception("You may only specify up to five originators to filter on.");
  }
  while (idList.Count < 5) { idList.Add(-1); }  // -1 is an impossible value
  return ExecuteQuery<PublishDate>(getValuesInListSQL, 
               origCount,   
               idList[0], idList[1], idList[2], idList[3], idList[4]);

基本上，如果count为0，那么就没有过滤器，所有东西都会通过。如果计数高于0，则该值必须在列表中，但列表已被填充为5个不可能的值(因此SQL仍然有意义)

有时蹩脚的解决方案是唯一真正有效的。

在SQL SERVER 2016或更高版本中，您可以使用STRING_SPLIT。

DECLARE @InParaSeprated VARCHAR(MAX) = 'ruby,rails,scruffy,rubyonrails'
DECLARE @Delimeter VARCHAR(10) = ','
SELECT 
    * 
FROM 
    Tags T
    INNER JOIN STRING_SPLIT(@InputParameters,@Delimeter) SS ON T.Name = SS.value
ORDER BY 
    Count DESC

我使用这个是因为在我的查询中，有时连接速度比Like操作符快。 此外，您还可以按您喜欢的任何单独格式输入无限数量的数据。 我喜欢这个。

这可能是一种有点讨厌的方法，我用过一次，相当有效。

根据你的目标，它可能会有用。

创建一个只有一列的临时表。 将每个查找值插入到该列中。 不使用IN，只需使用标准JOIN规则。(灵活性++)

这为您所能做的事情提供了一些额外的灵活性，但它更适合这样的情况:需要查询一个大型表，有良好的索引，并且希望多次使用参数化列表。节省了执行两次，所有的卫生工作都是手动完成的。

我从来没有时间去分析它到底有多快，但在我的情况下，它是需要的。

另一种可能的解决方案是，不向存储过程传递可变数量的参数，而是传递一个包含您要查找的名称的字符串，但通过将它们围绕在'<>'中使它们唯一。然后使用PATINDEX查找名称:

SELECT * 
FROM Tags 
WHERE PATINDEX('%<' + Name + '>%','<jo>,<john>,<scruffy>,<rubyonrails>') > 0

这很恶心，但如果你保证至少有一个，你可以这样做:

SELECT ...
       ...
 WHERE tag IN( @tag1, ISNULL( @tag2, @tag1 ), ISNULL( @tag3, @tag1 ), etc. )

有IN('tag1'， 'tag2'， 'tag1'， 'tag1'， 'tag1')将很容易被SQL Server优化掉。另外，你可以直接搜索索引