【发布时间】：2020-01-24 17:39:45
【问题描述】：
我正在研究是否以及何时可以使用合并语句。
多年前，我遇到过许多不同的错误，这些错误会导致大量错误或严重的性能问题。
我最近来到一个新地方工作，他们使用合并语句及其标准做法。我正在尝试查找有关错误/疑虑/性能是否已解决的最新文章。
我做了一些简单的谷歌搜索，有一篇文章最后更新于 2018 年 7 月 24 日，讨论了 SQL Server 上的合并。
它列出了一长串已知问题及其最后的已知状态。
我已经深入研究了它们，看起来没有任何“主要”错误会影响我们的工作场所。
所以，我的问题是：
Merge 性能好吗？
理论上应该，但我找不到任何关于它的文章或示例。
我正在找人向我解释或指出正确的方向，说明 SQL 合并语句现在是否有效并且可以用作标准做法，而不是插入/更新/删除单独的调用。
【问题讨论】：
-
已经有一段时间了，我的记忆在这里模糊，因此只是一个评论。但如果我没记错的话，merge 的 main 问题是您仍然必须有效地编写完整的测试、插入和更新语句，并且它们仍然不能保证在检查和行动。换句话说，开发人员的工作量仍然与在事务中使用 UPSERT 模式一样多，但没有安全性。
-
我记得有一件有趣的事情，触发器也被触发了。如果合并语句变得复杂，程序员往往难以阅读。我建议不要使用它们，而是在事务中拆分为多个操作。
-
MERGE的问题是双重的，即使在修复了所有错误之后：对于琐碎的情况，它仍然不像事务中的单独语句那样灵活和易于阅读，对于复杂的情况仅仅理解这些语句就足够棘手了，更不用说弄清楚如何减轻/解决任何锁定问题了。理论上MERGE很棒，但实际上它往往会引入比实际解决的问题更多的问题。它有其用途（尤其是与OUTPUT结合使用时），但我绝对不建议将其作为“标准做法”。 -
Aaron Bertrand 就这个话题写了great article。它有点过时了，但许多事情没有或不会被修复，而列出的一些项目已经修复。当它被引入时，它看起来非常棒，但是对于即使是远程复杂的情况，它的语法也很迟钝，我通常只做标准更新，然后再插入。它更容易维护。
标签： sql-server merge sql-update sql-insert sql-delete