小编Neg*_*sro的帖子

我的公司正在努力实施一个新的 HR 应用程序，以统一我们现有的 HR 流程。不过，我们遇到了一些症结；根据业务规则，Employee表的EmployeeID和SupervisorID列不能为空。但是，应用程序要求这些列可以为空，并且不会在将列设置为不允许为空时同步这些列。

建议的解决方案是创建一个视图，其中架构似乎允许列中存在空值，同时保留表以防止它们被输入到数据中。我并不完全相信这是可能的，而且我一直无法找到一种方法来做到这一点。这可能吗？如果没有，处理这种情况的最佳方法是什么？

最近，我正在解决一个奇怪的性能问题，该问题影响了应用程序的生产环境，但不影响任何较低的环境。我设法用这个查询以最简单的形式复制了这个问题：

SELECT product_id, dbo.TranslateStatusToActive(status_id) FROM prod_Products

TranslateStatusToActive是一个非常简单的标量 UDF，它基本上只是连接给另一个表的值，并根据case语句返回 1 或 0 。我会发布代码，但它是供应商编写的功能，我今天对被起诉并不特别感兴趣。（是的，逻辑可以内联。是的，它解决了性能问题。是的，我们已经说服供应商实施更改。这不是我的问题。）

在生产中执行时，查询需要 10 到 20 秒才能返回结果。在开发中，相同的查询在不到 3 秒的时间内返回。执行计划几乎相同，除了显示 CPU 时间在生产中约为 15000 毫秒，其他地方为 3000 毫秒。

我怀疑存在一些环境差异，因此我设置了另一台服务器来尽可能地复制生产条件：我确保 CPU 的数量、分配给 SQL Server 的内存量以及特定的补丁级别 (13.0.0.1)。 4451) 相同。

我将生产数据库的副本恢复到这个新的沙箱服务器，令我惊讶的是，查询的执行速度与它在开发中的执行速度一样快。再一次，计划和数据是相同的，除了额外的 CPU 时间。执行计划中列出的等待类型相同，并且在每个环境中彼此相差几毫秒。

不知道接下来要做什么，我optimize for ad hoc workloads在生产服务器上启用了。这解决了性能问题！但是有一件事：其他环境都没有启用此设置。我一直在测试期间定期清除每个环境中的程序和系统缓存，所以我认为这不是更改设置导致重新编译的结果。

问题

• 尽管有相同的计划和几乎相同的系统，但什么可能导致 UDF 在每个环境中运行如此不同？
• 为什么需要optimize for ad hoc workloads启用生产环境才能与未启用它的其他环境一样好？
• 是否有一些我没想到检查的设置可能会导致如此大的差异？

开发是共享的，而生产目前仅由该应用程序使用。第三个盒子的用法和生产的盒子几乎一样。我几乎清除了他们发出DBCC命令的每个缓存。开发环境经常用作培训系统，所以我相当确信这不是计划缓存问题。

与第三个框的唯一区别是没有连接到它的应用程序，但是在我在生产中测试该功能时几乎没有使用应用程序，所以区别在于，基于我在这种环境中工作的经验，微不足道。我唯一不能做的就是重启生产服务器，但微软的文档明确指出启用optimize for ad hoc workloads不会清除或影响任何现有计划，所以我看不出有什么区别。