SQL IN是否对性能不利？

Question

我有做类似的查询：

SELECT FieldX, FieldY FROM A

WHERE FieldW IN (108, 109, 113, 138, 146, 160,

307, 314, 370, 371, 441, 454 ,457, 458, 479, 480,

485, 488, 490, 492, 519, 523, 525, 534, 539, 543,

546, 547, 550, 564, 573, 629, 642, 643, 649, 650,

651, 694, 698, 699, 761, 762, 768, 772, 773, 774,

775, 778, 784, 843, 844, 848, 851, 852, 853, 854,

855, 856, 857, 858, 859, 860, 861, 862, 863, 864,

865, 868, 869, 871, 872, 873, 891) 

具有很多选项的IN子句是否对查询性能不利？我的应用程序遇到很多超时，我相信这可能是此类问题的根源。是否可以使用任何良好的SQL提示优化查询而不删除数字？

编辑：

@KM这些是不同表中的键。这是一个论坛应用程序，简要说明：c＃从数据库获取所有论坛并将其存储在应用程序缓存中。在C＃调用获取这些论坛和该用户线程的过程之前，c＃会考虑权限和一些业务逻辑，执行一些逻辑过滤“所有论坛”集合的逻辑。超时发生在数据库而不是应用程序本身。对查询执行所有这些逻辑将需要大量内部联接，而且我不确定100％是否可以在过程内完成所有这些操作。

我正在使用SQL Server 2000

Answer 1

使用IN运算符编写查询时，有一些注意事项，它们可能会影响性能。首先，大多数数据库通常在内部重写IN子句以使用OR逻辑连接符。因此col IN ('a','b','c')被重写为：(COL = 'a') OR (COL = 'b') or (COL = 'c')。假设您在上有一个索引，则这两个查询的执行计划可能等效col。其次，当对可变数量的参数使用IN或OR时，每次参数更改时，都将导致数据库不得不重新解析查询并重建执行计划。为查询建立执行计划可能是一个昂贵的步骤。大多数数据库使用EXACT查询文本作为键来缓存它们运行的查询的执行计划。如果执行类似的查询，但谓词中的参数值不同，则很可能导致数据库花费大量时间来解析和构建执行计划。这就是为什么强烈建议将绑定变量作为确保最佳查询性能的一种方式。第三，许多数据库对它们可以执行的查询的复杂性有一个限制-这些限制之一是谓词中可以包含的逻辑连接词的数量。在您的情况下，几十个值不太可能达到数据库的内置限制，但是如果您希望将数百或数千个值传递给IN子句，则肯定会发生。在这种情况下，数据库将简单地取消查询请求。第四，在谓词中包含IN和OR的查询不能总是在并行环境中最佳地重写。在许多情况下，没有应用并行服务器优化-MSDN对如何优化并行查询进行了不错的介绍。通常，尽管如此，使用UNION ALL运算符的查询在大多数数据库中都是微不足道的-并在可能的情况下首选逻辑连接符（例如OR和IN）。