IGNORE_DUP_KEY = ON基本上告诉SQL Server插入非重复行，但是默默地忽略任何重复行;默认行为是引发错误并在不允许它们的列中存在重复时中止整个事务。
我已经处理了大量数据，这些数据通常至少有一个副本，但是当我知道一个值不应该有重复时，我喜欢使用UNIQUE约束;然而，当我尝试批量加载数据时，我想要的最后一件事就是它完成了90％，然后突然遇到重复并错误地解决了整个事情（是的，我知道明显的解决方案是确保没有重复，但有时我只是递给一个填充数据的电子表格并告诉他尽快加载它。
那么，默认为OFF的原因是什么，以及为什么不会您希望它一直处于开启状态，以便任何非重复条目成功你不必担心任何重复;无论如何，重复的可能性都在那里。
它与性能或其他相关吗？这似乎是一个好主意，但必须有一些理由说明它不是默认行为。
主要是，有很好的理由不使用我应该知道的，或者是否应该根据具体情况进行评估？
答案 0 :(得分：16)
每当数据库中存在与“正常”的偏差时，您可能想知道它。
您保持密钥的独特性是因为业务需求引起的一些限制因素而决定了它。数据库只是保持在交易的一边说'嘿，你希望这是独特的，但现在你说的是相反的事情。下定决心'
如果这是故意的，您可以通过使用IGNORE_DUP_KEY请求数据库关闭：）
答案 1 :(得分：2)
我想这可能是因为默认设置是为了防止任何无效的事务无声地失败。考虑到一切，我宁愿选择何时忽略意外后果，但除非我另有说明，否则请告诉我。
示例：如果我存入我的薪水，我希望有人注意到我的雇主是否意外发出了重复的支票号码。
答案 2 :(得分：1)
它可以用作健全性检查。如果您知道应该没有冲突，请将其关闭，并且它会在错误上快速失败。 OTOH用于临时控制台会话，我明白你的观点。
答案 3 :(得分：1)
我有多对多的关系。我有一个具有唯一索引的产品到类别表，没有其他数据而不是表中的prodid和katid。
所以我在唯一（prodid，katid）索引上设置IGNORE_DUP_KEY。
所以我可以安全地说“将产品（1,2,3）添加到类别（a，b，c）”，而无需检查某些产品是否已经在某些类别中;我只关心最终结果。