有人说最好制作查询以避免重复的键异常，但我不相信这比仅设置IGNORE_DUP_KEY = ON索引更有效。
我的目标是在尝试更新这些行之前确保一个或多个用户存在一行或一组行。我这样做，以便当我尝试使用如下所示的更新语句更新行并且没有行受到影响时，这是因为[Count]谓词的部分不满足，而不是根本不存在的行（即[ID]不满足谓词的部分）：
UPDATE [Inventory]
SET [Count] = [Count] + 1
WHERE [ID] = 3
AND ([Count] + 1) <= @MaxInventory
我可以运行EXISTS(SELECT 1 From [Inventory] WHERE [ID] = 3以检查该单行，并且仅在该行不存在时才插入该行。这只是避免了不必要的插入。如有必要，插入仍然必须与并发事务竞争，因此仍然可能发生重复键异常。
我很好奇IGNORE_DUP_KEY在这种情况下仅打开而不是允许抛出和捕获错误是否更高效。具体来说，我很好奇它是否与运行存在检查一样快甚至可能更快，只是尝试插入记录并让它忽略重复的键。
当我一次检查和初始化多个记录时，这变得更加重要。例如，如果我需要确保在单个更新语句中存在数千个用户的记录，那么如果我只是预先运行该插入语句，让它忽略重复的键，那么逻辑会简单得多。避免重复会更复杂，因为我必须首先查询不存在记录的表，然后尝试仅添加这些记录（同样，忽略重复键）。即使所有记录都存在，仅插入可能会更快。
我可以在中途遇到它并检查是否缺少任何记录，例如左连接或COUNT比较，但是如果忽略重复键的插入更快，为什么还要麻烦呢？
IGNORE_DUP_KEY使用并尝试插入而不是提前检查行是否存在是一个好主意吗？如果不是，为什么？
这绝对是为索引启用的非典型设置。我认为您不会找到很多人跳起来谈论使用它。
当然，Paul White 有几篇关于这个主题的有用帖子：
如果您关心的是 upsert 模式（或类似的东西），Michael Swart 的这篇文章非常有用：
每个功能都有一个用例，
IGNORE_DUP_KEY也不例外。正如我在IGNORE_DUP_KEY 在聚集索引上较慢中解释的那样，此选项仅在重复键异常的数量足够少时才可能提高性能（在聚集索引上）。
收支平衡点取决于系统，需要实际测试才能正确评估。尽量不要提前做出假设或判断。仔细测试每个健壮的实现替代方案，并选择在您的场景中最有意义的一个。
作为性能意外原因的一个示例，请考虑索引插入点必须位于某个阶段，因此重复该操作可能比预期的要便宜。当 SQL Server 可以使用“行集共享”优化时，开销就更少了。引擎在检查是否存在时定位插入点一次，并为插入操作保留该直接引用。
虽然与问题没有直接关系，但我应该提到一些使用注意事项
IGNORE_DUP_KEY：MERGE语句的插入活动不尊重它。我通常更喜欢单独的语句
MERGE而不是 ，但您应该针对您的预期用途对其进行测试。MERGE可以将插入和更新组合到单个语句中，同时利用漏洞填充优化和行集共享。我们
IGNORE_DUP_KEY = ON用于我们的ETL流程，其中源流数据通常带有重复项。我们无法控制它。它运作良好。
我们不会将它用于我们的最终运营数据。
我还没有找到它的任何其他用途。