由于WHERE子句中的条目超过100,000个，导致SQL Server错误8632
我的问题（或至少是错误消息）与查询处理器用尽内部资源非常相似-极长的sql查询。 我的客户正在使用SQL选择查询，其中包含一个正好有100,000个条目的子句。 查询失败，出现错误8632和错误消息 内部错误：已达到表达式服务限制。请在查询中查找可能复杂的表达式，然后尝试简化它们。） 我非常奇怪地抛出此错误消息，恰好在100,000个条目处，所以我想知道这是否是可配置的值。是这种情况，如果是的话，如何将该值增加到更高的值？ 在MSDN上，建议重新编写查询，但我想避免这种情况。 同时，我发现我正在谈论的条目列表包含自然数，其中有些看起来似乎是连续的（例如（1,2,3,6,7,8,9,10,12， 13,15,16,17,18,19,20）。 这使得SQL的子句类似于： where entry in (1,2,3,6,7,8,9,10,12,13,15,16,17,18,19,20) 我可以将其转换为： where (entry between 1 and 3) OR (entry between 6 and 10) OR (entry between 12 and 13) OR (entry between 15 and 20) 可以通过以下方式将其缩短： where entry in (1,...,3,6,...,10,12,13,15,...,20) ...或类似的东西？（我知道这是一个长期的尝试，但这会使软件更新更容易且更具可读性） 供您参考：where子句中的数据是在另一个表上完成的计算结果：首先在该表的开头读取并过滤该表的条目，然后再进行一些额外的处理（使用SQL），这种额外处理的结果是更多的过滤，其结果在where子句中使用。由于不可能用SQL编写完整的过滤，因此使用了上述方法。显然，子句的内容可能在每个处理过程中都发生变化，因此需要动态解决方案。