IGNORE_DUP_KEY = ON基本上告诉 SQL Server 插入非重复行，但默默地忽略任何重复项；默认行为是当列中存在不允许的重复项时引发错误并中止整个事务。
我处理过大量数据，这些数据通常至少有一个重复项，而实际上不应该有，所以我喜欢利用UNIQUE当我知道一个值不应该有重复时的约束；然而，当我尝试批量加载数据时，我最不想做的就是让它完成 90%，然后突然遇到重复项并出错（是的，我知道明显的解决方案是确保没有重复项） ，但有时我只是收到一个充满数据的电子表格，并被告知尽快加载）。
那么，默认的原因是什么？OFF，以及为什么wouldn't您希望它始终处于打开状态，以便任何非重复条目都能成功，同时您不必担心任何重复项；无论如何，重复项很可能是错误地存在在那里的。
是跟性能有关，还是其他什么？这似乎是一个好主意，但一定有一些原因导致它不是默认行为。
主要是有没有充分的理由not使用我应该注意的这一点，还是应该根据具体情况进行评估？
每当数据库中存在与“正常”情况的偏差时，您可能想了解它。
由于业务需求所带来的一些限制，您保持了密钥的唯一性。数据库只是坚持其协议的一面，说‘嘿，你希望这是独一无二的，但现在你说的是相反的话。下定决心’
如果这是故意的，您可以使用 IGNORE_DUP_KEY 要求数据库关闭:)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
