Sql server 如何规避Sybase ASE和SQL Server的最大绑定值数

我正在为表单的大型条件运行集成测试

其中x在：1，：2，：3，：4，，：3001，：3002 上面的示例描述了in条件中有许多绑定变量。众所周知，Oracle的限制是在IN条件的括号之间绑定1000个值或内联值。解决方案很简单，只要写下：

WHERE x IN (:1, :2, :3, :4, ..., :1000) OR x IN (:1001, ...)

---

另一方面，Sybase ASE 15.5和SQL Server 2008 R8似乎对绑定值的数量有总体限制：Sybase ASE为2000，SQL Server为2100。换句话说，似乎无法使用这两个数据库的绑定值拆分/转换上述条件。除了内联所有绑定值之外，还有什么办法可以避免这个问题吗？

如果您创建一个表类型，然后在@variableThatIsMyTableType的SELECT列中说，那么您就完全不受限制了

我不会反刍MSDN，它涵盖了

然后生成的SQL类似于：

DECLARE @variableThatIsMyTableType mySchema.myTableType
INSERT @variableThatIsMyTableType VALUES (1)
INSERT @variableThatIsMyTableType VALUES (2)
EXEC proc @variableThatIsMyTableType

---

然而，当从C和SqlClient提交时，它创建了所谓的“琐碎计划”——您可以阅读关于TVP和琐碎计划以及。通过SQL direct执行此操作将导致缓存计划，因此您的里程数可能会有所不同。

我们最终在中实现此功能的方法是，一旦遇到任何限制，使用ControlFlowException中止使用绑定值呈现SQL。限制如下：

SQLite:999 安格尔10.1.0:1024 Sybase ASE 15.5:2000 SQL Server 2008:2100 我们也在这里写了关于这一点的博客：

一旦达到此限制，ControlFlowException将在查询呈现站点捕获，在该站点中，它只需使用所有内联的绑定值重新呈现—当然，在达到查询大小限制（如果有的话）之前，它始终有效

---

我们假设在这些情况下，内联绑定值和重复的硬解析都是可以的，因为执行计划能够在这种高度动态的SQL中真正重用的可能性很小。

这看起来确实是一种可行的方法来避免这个问题。另一方面，我完全可以控制jOOQ提供的SQL，因此在本例中，内联所有绑定变量比创建临时表类型要简单。是的，这看起来确实像是“六个一个半另一个”的情况。