问是其中的ID IN (1，2，3，4，5，...)效率最高的？

EN

我知道这个话题已经被打死了，但似乎互联网上的许多文章往往是在寻找最优雅的方法，而不是最有效的方法如何解决它。这是问题所在。我们正在构建一个应用程序，其中一个常见的数据库查询将涉及基于用户提供的ID列表的操作(SELECT和UPDATE)。有问题的表预计将有数十万行，用户提供的ID列表可能是无界的，但它们很可能是数十或数百行(出于性能原因，我们稍后可能会限制它)。

如果我对数据库一般工作原理的理解是正确的，那么最有效的方法就是简单地使用WHERE ID IN (1, 2, 3, 4, 5, ...)构造并动态构建查询。问题的核心是ID的输入列表实际上是任意的，所以无论数据库有多聪明，或者我们实现它有多聪明，我们总是从一个随机的整数子集开始，所以最终每种方法都必须在内部归结为像WHERE ID IN (1, 2, 3, 4, 5, ...)这样的东西。

人们可以在web上找到许多方法。例如，需要声明一个表变量，将ID列表作为逗号分隔的字符串传递给存储过程，在存储过程中将其拆分，将ID插入表变量并在表变量上连接主表，即如下所示：

-- 1. Temporary table for ID’s:
DECLARE @IDS TABLE (ID int);

-- 2. Split the given string of ID’s, and each ID to @IDS.
-- Omitted for brevity.

-- 3. Join the main table to @ID’s:
SELECT MyTable.ID, MyTable.SomeColumn
FROM MyTable INNER JOIN @IDS ON MyTable.ID = @IDS.ID;

把字符串操作的问题放在一边，我认为在这种情况下，在第三步中SQL Server会说：“谢谢，这很好，但我只需要ID的列表”，它扫描表变量@IDS，然后在MyTable中执行n次查找，其中n是ID的数量。我已经做了一些初步的性能评估，并检查了查询计划，看起来就是这样发生的。因此，表变量、字符串连接和拆分以及所有额外的INSERT都是没有意义的。

我说的对吗？还是我错过了什么？真的有更聪明、更有效的方法吗？基本上，我要说的是SQL Server无论如何都要做n次索引查找，将查询格式化为WHERE ID IN (1, 2, 3, 4, 5, ...)是请求它的最直接的方式。