Neg*_*sro 2 performance sql-server functions sql-server-2016 query-performance
最近，我正在解决一个奇怪的性能问题，该问题影响了应用程序的生产环境，但不影响任何较低的环境。我设法用这个查询以最简单的形式复制了这个问题：
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在生产服务器上启用了。这解决了性能问题！但是有一件事：其他环境都没有启用此设置。我一直在测试期间定期清除每个环境中的程序和系统缓存，所以我认为这不是更改设置导致重新编译的结果。
optimize for ad hoc workloads启用生产环境才能与未启用它的其他环境一样好？开发是共享的，而生产目前仅由该应用程序使用。第三个盒子的用法和生产的盒子几乎一样。我几乎清除了他们发出DBCC命令的每个缓存。开发环境经常用作培训系统，所以我相当确信这不是计划缓存问题。
与第三个框的唯一区别是没有连接到它的应用程序，但是在我在生产中测试该功能时几乎没有使用应用程序，所以区别在于，基于我在这种环境中工作的经验，微不足道。我唯一不能做的就是重启生产服务器，但微软的文档明确指出启用optimize for ad hoc workloads不会清除或影响任何现有计划，所以我看不出有什么区别。
你描述的，当有某种启用监控（跟踪，扩展事件会话，一些第三方工具），它确实某种每UDF执行记录或工作的可能发生的情况（甚至每条语句中的UDF）。
如果在查询中多次执行 UDF，则执行该监控的开销可能非常大。如果监控仅发生在一台服务器上，那么您会发现它们之间的性能差异很大。