在SQL Server中，我们通常使用用户定义的函数来编写SQL查询。UDF接受参数并将结果作为输出返回。我们可以在编程代码中使用这些UDF，并且可以快速编写查询。我们可以独立于任何其他编程代码来修改UDF。
在SQL Server中，我们具有以下类型的用户定义函数。
-
标量函数：标量用户定义的函数返回单个值。您将始终具有RETURNS子句。返回值不能是文本，图像或时间戳。以下是标量函数的示例。
Create FUNCTION dbo.ufnGetCustomerData (@CustomerID int) RETURNS varchar (50) AS BEGIN DECLARE @CustomerName varchar(50); SELECT @CustomerName = customername FROM [WideWorldImporters].[Sales].[Customers] C WHERE C.CustomerID=@CustomerID RETURN @CustomerName; END;
传统上，标量用户定义函数不被认为是高性能的好选择，但是SQL Server 2019提供了一种提高这些标量用户定义函数的性能的方法。我们将在本文的后一部分中了解更多有关它的信息。
-
多语句表值函数（TVF）：其语法类似于标量用户定义函数，并提供多值作为输出。由于基数估计问题，这些性能也不优化。
SQL Server 2012提供固定的基数估计，而SQL Server 2012提供的基数估计为100。SQLServer 2017使用称为交错执行的功能改进了这些MSTVF的基数估计。
-
内联表值函数：内联表值函数是性能优化的函数。它们不包含表定义。此函数内部的查询批处理是一条语句，因此，当我们以批处理或循环方式使用它时，它不会提供任何性能问题。
下面是内联表值函数的示例。
USE [WideWorldImporters] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE FUNCTION [Application].[DetermineCustomerAccess](@CityID int) RETURNS TABLE WITH SCHEMABINDING AS RETURN (SELECT 1 AS AccessResult WHERE IS_ROLEMEMBER(N'db_owner') <> 0 OR IS_ROLEMEMBER((SELECT sp.SalesTerritory FROM [Application].Cities AS c INNER JOIN [Application].StateProvinces AS sp ON c.StateProvinceID = sp.StateProvinceID WHERE c.CityID = @CityID) + N' Sales') <> 0 OR (ORIGINAL_LOGIN() = N'Website' AND EXISTS (SELECT 1 FROM [Application].Cities AS c INNER JOIN [Application].StateProvinces AS sp ON c.StateProvinceID = sp.StateProvinceID WHERE c.CityID = @CityID AND sp.SalesTerritory = SESSION_CONTEXT(N'SalesTerritory')))); GO
标量用户定义函数
如上所述，标量用户定义的函数不会在SQL Server中提供性能优势。因此，在本节中，我们将首先查看标量用户定义函数的性能问题，然后使用SQL Server 2019比较性能。
对于此示例，我正在运行SQL Server 2019 2.1和WideWorldImporters数据库。
将数据库兼容性级别设置为140。
USE [master] GO ALTER DATABASE [WideWorldImporters] SET COMPATIBILITY_LEVEL = 140 GO
使用数据库范围的配置选项清除过程缓存。这将从所有存储的执行计划或缓存中清除我们的数据库。
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE ; Go
现在，在WideWorldImporters数据库中创建标量用户定义函数。此函数将根据说明返回数量。执行以下脚本。
CREATE OR ALTER FUNCTION Sales.SalesQuantity (@Description NVARCHAR(100)) RETURNS SMALLINT AS BEGIN DECLARE @Count SMALLINT SELECT @Count= Quantity FROM Sales.OrderLines WHERE Description=@Description; RETURN(@Count) END; GO
我们可以使用类似于表列对象的功能。运行以下命令，该命令将UDF函数用作普通表列。
SET STATISTICS IO ON SET STATISTICS TIME ON SELECT Sol.orderid, sol.Description, Sales.SalesQuantity(sol.Description) as quantity, PickedQuantity FROM Sales.Orders as so JOIN Sales.OrderLines as sol on so.OrderId=sol.OrderID WHERE sol.PickingCompletedWhen >'2013-01-01 11:00:00.0000000' ORDER BY UnitPrice DESC GO
在上面的屏幕截图中，您可以看到大约花了18分钟来处理228,176条记录。
现在让我们以兼容级别150（SQL Server 2019）运行相同的查询。
USE [master] GO ALTER DATABASE [WideWorldImporters] SET COMPATIBILITY_LEVEL = 150 GO ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE ; Go
使用此已修改的兼容性级别再次运行查询。
在SQL Server 2019中，您可以注意到查询仅用19秒就完成了处理228,176行，而SQL Server 2016中则是12分钟。相对而言，处理这些结果非常快。
现在让我们在SQL Server 2016和SQL Server 2019数据库兼容性级别中再次运行查询，并捕获统计数据IO和统计时间以及要与之进行比较的实际执行计划。
SQL Server 2019统计信息输出
（受影响的228176行）
表'OrderLines'。扫描计数5，逻辑读857，物理读0，预读0，lob逻辑读180，lob物理读0，lob预读0。
表'OrderLines'。段读取为2，段跳过0。
表为“工作表”。扫描计数227，逻辑读730037，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。
表'Workfile'。扫描计数0，逻辑读0，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。
（受影响的1行）
SQL Server执行时间：
CPU时间= 15287毫秒，经过的时间= 18782毫秒。
SQL Server解析和编译时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server执行时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server 2016统计信息输出
SQL Server解析和编译时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server执行时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server解析和编译时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server执行时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server执行时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
（受影响的228176行）
表“工作表”。扫描计数0，逻辑读0，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。
表'OrderLines'。扫描计数1，逻辑读3504，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。
（受影响的1行）
SQL Server执行时间：
CPU时间= 1071719 ms，经过的时间= 1109655 ms。
SQL Server解析和编译时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server执行时间：
CPU时间= 0毫秒，经过的时间= 0毫秒。
如果将执行级别与兼容性级别140（SQL Server 2017）和兼容性级别150（SQL Server 2019）进行比较，则可以看到CPU时间和运行时间有了显着改善。
在下表中，您可以看到Scalar用户定义函数与SQL Server 2019的性能优化比较
|
SQL Server兼容性级别140 |
SQL Server兼容性级别150 |
性能改进 |
|
CPU – 1,071,719毫秒 |
CPU 15,287毫秒 |
1,056,432毫秒 |
|
经过时间1,109,655毫秒 |
经过时间18,782毫秒 |
1,090,873毫秒 |
执行计划比较
在本节中，我们将比较在使用SQL Server 2019及更高版本运行标量UDF时的执行计划。
以下是我们以兼容级别140（SQL Server 2017或更低版本）运行标量UDF时的实际执行计划
在估算的执行计划中，我们将对此有一个更清晰的认识。在下面的计划中，它显示了查询和UDF函数的单独执行计划。因此，SQL Server在SQL Server 2017之前将标量UDF函数视为一个单独的标识。每次调用此UDF函数时，SQL Server都需要做额外的工作。
现在，如果我们查看SQL Server 2019中的实际估计计划，我们将获得一个较早执行计划的复杂计划，如下图所示。在SQL Server 2019中，由于内联功能，它能够将UDF操作合并到单个查询计划中。
在此执行计划中，它在下部区域显示了UDF。您可以看到多个运算符来执行查询。SQL Server 2019内联标量UDF以优化查询的执行。它不会将此UDF视为单独的标识，但是会像正常的select语句一样运行它。因此，我们获得了CPU，内存，执行时间等方面的性能优势。
我们可以检查SQL Server是否能够内联特定标量UDF。SQL Server 2019在sys.sql_modules中引入了新列is_inlineable。运行以下查询，并在其中传递标量函数名称。在下面的查询中，我们的UDF显示值1，这意味着SQL Server 2019可以倾斜此函数。
select o.name, sm.is_inlineable from sys.sql_modules sm join sys.objects o on sm.object_id = o.object_id where o.name = 'SalesQuantity';
在SQL Server 2019中内嵌标量UDF的条件
如果满足以下条件，则SQL Server 2019可以内联标量函数。
- UDF不是分区函数
- 没有引用任何表变量
- 没有使用任何计算列。
- 不能在Group By子句中调用UDF
- 可以在标量UDF中使用以下构造
-
- Declare
- Select
- If/ else
- Return
- Exits or IsNull
- UDF没有包含任何与时间有关的函数。
使用SQL Server 2019 UDF倾斜功能的不同方法。
我们可以通过以下方式在SQL Server 2019中使用此UDF内联功能。
- 将数据库兼容性级别设置为150（SQL Server 2019）
-
我们可以使用新的数据库处理配置来控制此行为。您可以在下面的数据库作用域配置列表中看到，我们有了新的选项TSQL_SCALAR_UDF_INLINING
--Run the below query to turn on Scalar UDF Inlining in a particular database ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = ON; -- Run the below query to turn off Scalar UDF Inlining in a particular database ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF;
-
我们还可以通过指定查询提示来禁用特定查询的标量UDF内联：
DISABLE_TSQL_SCALAR_UDF_INLINING
在此示例中，我们使用以下参数禁用了UDF内联
'OPTION(USE HINT ('DISABLE_TSQL_SCALAR_UDF_INLINING'))'
注意：如果我们已为标量UDF内联启用数据库作用域配置，并使用查询提示在查询级别禁用此功能，则SQL Server将优先提示数据库作用域配置或兼容性级别设置。
-
创建标量UDF时，我们可以指定也关闭此功能。我们需要在以下示例中指定WITH INLINE = OFF
默认情况下，在SQL Server 2019中启用了标量UDF内联，因此，我们不需要指定参数WITH INLINE = ON。如果需要，可以指定它。
结论：
在本文中，我们探讨了由于内联导致标量UDF的显着性能改进。这些增强功能会给开发人员和管理员带来微笑。