sql - 用户自定义函数性能劣势

Question

我有一个包含大量 UDF 的数据库，其中包含一个涉及大量数据操作和计算的长时间运行的进程。

我在使用 UDF 时的想法是从底层表中分离出逻辑信息单元。例如，如果我试图获取有关汽车的信息，我可能有几个表，如颜色、型号、年份等，每次我都必须加入这些表才能获得汽车。相反，我会使用类似 fnCar() 的函数来获取数据的非规范化 View 。

我在长时间运行的过程中经常调用这些函数，我想知道如果我有一个非规范化的工作表、 View 或临时表来进行数据操作和计算是否会更好。一般来说，在性能方面我应该注意使用 UDF 有什么缺点吗？

例如，我使用 UDF 进行一些计算。然后，我对该数据进行逆透视并将其存储在表中。每当我需要再次使用该数据时，我都会调用 UDF 将数据转回。我们这样做的原因是为了保持计算的灵 active 。如果我们添加/删除/更改计算，我们不想更改数据模型。

--Calculate some values in a function

declare @location table
(
    id int,
    lattitude float,
    longitude float
)

insert into @location select  1, 40.7, 74
insert into @location select  2, 42, 73
insert into @location select  3, 61, 149
insert into @location select  4, 41, 87


declare @myLattitude float
declare @myLongitude float
set @myLattitude =43
set @myLongitude = 116

declare @distance table
(
    id int,
    distance float
)

insert into @distance
select id, sqrt(power(lattitude-@mylattitude,2)+power(longitude-@mylongitude,2))
from @location



--Store unpivoted data in a table
declare @unpivot table
(
    id int,
    attribute varchar(100),
    attributeValue float
)

insert into @unpivot
(
    id,
    attribute,
    attributeValue
)
select id
    ,attribute
    ,attributevalue 
from
(
    select 
        L.id,
        L.Lattitude, 
        L.Longitude,
        D.Distance
    from @location L 
        inner join @distance D 
        on L.id=D.id
) a
unpivot 
(
    attributeValue for attribute in
    (lattitude, longitude, distance)
) x

--retrive data from store via pivoting function for reporting

select * 
from @unpivot
pivot 
(
    max(attributeValue) for Attribute in (lattitude, longitude, distance)

) x

Answer 1

我会尝试回答

简单地说:你在使用 UDF 时做错了

当你使用 UDF 时，你会添加这些问题

1. RBAR(见底部)处理
   当您在 SELECT 子句中使用具有表访问权限的标量 UDF 时
   也就是说，不是高效的 JOIN，而是强制每行查找表”

2. 使用多语句 TVF 进行黑盒处理
   每个 TVF 都必须运行完成，并被视为“黑匣子”

您通常做的是加载一个平面暂存表，然后加入查找表，处理作为一个集合完成。如果这就是您所说的“非规范化”的意思，那么是的，它可能效果更好。

将 UDF 用于“信息的逻辑单元”是 OO/过程思维。 SQL是基于集合的。对于在 native /CLR 代码中运行的对象或对象集合来说，看起来正常的情况对于通过查询优化器进行的基于集合的数据处理失败。

注意:RBAR = 按痛苦行排列。有关更多信息，请参阅 Simple Talk's article