Sql server 为什么不将IGNORE_DUP_KEY设置为ON？

IGNORE\u DUP\u KEY=ON

基本上是告诉SQL Server插入不重复的行，但悄悄地忽略任何重复的行；默认行为是在列中存在不允许的重复项时引发错误并中止整个事务

我处理过大量的数据，这些数据通常至少有一个副本，但不应该有副本，所以当我知道某个值不应该有副本时，我喜欢使用

UNIQUE

约束；然而，当我尝试批量加载数据时，我最不希望的事情是它完成90%，然后突然遇到一个副本，并将整个过程出错（是的，我知道显而易见的解决方案是确保没有副本，但有时我只是被交给一个装满数据的电子表格，并被告知尽快加载）

那么，将默认值设置为关闭的原因是什么，以及为什么不希望它一直处于打开状态，以便任何非重复项都能成功，而不必担心任何重复项；无论如何，复制品很可能是错放在那里了

它是与性能有关，还是其他什么？这似乎是一个好主意，但它不是默认行为肯定是有原因的

---

主要是，是否有一个好的理由不使用它，我应该知道，还是应该根据具体情况进行评估？

它可以用作一种健全性检查。如果您知道不应该有冲突，请将其关闭，它将在bug上快速失败。对于临时控制台会话，我明白你的意思。

我想可能是因为默认设置是为了防止任何无效事务以静默方式失败。从各方面考虑，我更愿意选择何时忽略意外后果，但请让我知道，除非我另有说明

---

示例：如果我正在存入工资支票，我希望有人注意到我的雇主是否意外地签发了重复的支票号码。

每当数据库中出现与“正常”的偏差时，您可能都想知道

您保持了密钥的唯一性，这是因为业务需求导致了一些约束。数据库只是保持它的交易方说，‘嘿，你希望这是独特的，但现在你说的是相反的。下定决心

如果这是有意的，您可以使用IGNORE\u DUP\u KEY:）要求数据库关闭

无论如何，复制品很可能是错放在那里了

我打赌他们是！它们是虫子。你当然想知道他们！默认情况下，

IGNORE\u DUP\u KEY

上的图灵是

隐藏bug

…通过破坏数据。（当然，数据库在物理上保持一致，但从业务逻辑的角度来看，数据仍然是错误的。）

从任何标准来看，这都是一个可怕的选择

---

在特殊情况下打开它，然后尽可能快地清除它，这样你就不会意外地隐藏bug。

我有一个多对多关系。我有一个产品分类表，它有唯一的索引，表中除了prodid和katid之外没有其他数据

所以我在unique（prodid，katid）索引上设置IGNORE_DUP_键

---

因此，我可以放心地说“将产品（1，2，3）添加到类别（a，b，c）”，而不必检查某些产品是否已经在某些类别中；我只关心最终结果。

True-我想这是为了决定“重复输入”的情况是否属于例外情况，以及您是否应该提出错误，或者干脆忽略它。这也是事实。我想最好的理由是，除非你告诉它，否则它会在谨慎方面出错并引发错误。但文档和问题都表明，你不能损坏你的数据，因为即使使用IGNORE_DUP_KEY=on duplicates，也不允许重复。@Francoisbullenger不确定你在说什么。当然，只有使用非唯一索引才能进行复制。它们是逻辑应用程序错误，而不是SQL Server中的错误。它不会损坏数据，因为它不会插入重复值，它只是跳过它而不会引发警告。@user3071296数据库在物理上是一致的，但插入的数据是错误的。从应用程序的角度来看，这是数据损坏。当应用程序销毁数据时，这是数据损坏。因此，如果您对启用了“忽略重复键”的表执行“插入到…选择…从…”操作，哪些数据会自动出错并损坏？一条注释，将“忽略”设置为“开”并非没有后果。如果您有标识列，您将看到由于重复而被忽略的每个插入的标识中都有跳过。在非聚集索引上启用此选项会对性能造成影响，并可能导致并发插入批次的严重范围锁定。因此，当您想一次插入多行而忽略重复项时，请仅在聚集键上应用它。@eremmel您刚刚保存了我的培根，谢谢您的评论！在过去的几天里，我一直把头撞在墙上，试图弄明白为什么我在没有可串行化隔离的情况下得到范围锁，而我的大脑中却有一个关于忽略重复键导致性能问题的小问题。快速搜索让我找到了这个帖子，你这个摇滚！我只希望这是一个完整的答案，这样就更明显了：）