和表值函数连接引发的性能问题

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
简介:
    最近调优过程中遇到一个问题,就是表值函数作为连接中的一部分时,可能会引起麻烦,本文会简单阐述表值函数是什么,以及为什么使用表值函数进行连接时会引发性能问题。


表值函数
    SQL Server中提供了类似其他编程语言的函数,而函数的本质通常是一段代码的封装,并返回值。在SQL Server中,函数除了可以返回简单的数据类型之外(Int、Varchar等),还可以返回一个集合,也就是返回一个表。

    而根据是否直接返回集合或是定义后再返回集合,表值函数又分为内联用户定义表值函数和用户定义表值函数(下文统称为表值函数,省去“用户定义”四个字)。

 

内联表值函数
    内联表值函数和普通函数并无不同,唯一的区别是返回结果为集合(表),而不是简单数据类型,一个简单的内联表值函数如代码清单1所示(摘自MSDN)。

CREATE FUNCTION Sales.ufn_CustomerNamesInRegion
                 ( @Region nvarchar(50) )
RETURNS table
AS
RETURN (
        SELECT DISTINCT s.Name AS Store, a.City
        FROM Sales.Store AS s
        INNER JOIN Person.BusinessEntityAddress AS bea 
            ON bea.BusinessEntityID = s.BusinessEntityID 
        INNER JOIN Person.Address AS a 
            ON a.AddressID = bea.AddressID
        INNER JOIN Person.StateProvince AS sp 
            ON sp.StateProvinceID = a.StateProvinceID
        WHERE sp.Name = @Region
       );
GO
代码清单1.一个简单的表值函数

 

用户定义表值函数
    而用户定义表值函数,需要在函数开始时定义返回的表结构,然后可以写任何代码进行数据操作,插入到定义的表结构之后进行返回,一个稍微负责的用户定义表值函数示例如代码清单2所示(摘自MSDN)。

CREATE FUNCTION dbo.ufnGetContactInformation(@ContactID int)
RETURNS @retContactInformation TABLE 
(
    -- Columns returned by the function
    ContactID int PRIMARY KEY NOT NULL, 
    FirstName nvarchar(50) NULL, 
    LastName nvarchar(50) NULL, 
    JobTitle nvarchar(50) NULL, 
    ContactType nvarchar(50) NULL
)
AS 
-- Returns the first name, last name, job title, and contact type for the specified contact.
BEGIN
    DECLARE 
        @FirstName nvarchar(50), 
        @LastName nvarchar(50), 
        @JobTitle nvarchar(50), 
        @ContactType nvarchar(50);
    -- Get common contact information
    SELECT 
        @ContactID = BusinessEntityID, 
        @FirstName = FirstName, 
        @LastName = LastName
    FROM Person.Person 
    WHERE BusinessEntityID = @ContactID;
    -- Get contact job title
    SELECT @JobTitle = 
        CASE 
            -- Check for employee
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'EM') 
                THEN (SELECT JobTitle 
                      FROM HumanResources.Employee AS e
                      WHERE e.BusinessEntityID = @ContactID)
            -- Check for vendor
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'VC') 
                THEN (SELECT ct.Name 
                      FROM Person.ContactType AS ct 
                      INNER JOIN Person.BusinessEntityContact AS bec 
                          ON bec.ContactTypeID = ct.ContactTypeID  
                      WHERE bec.PersonID = @ContactID)
 
            -- Check for store
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'SC') 
                THEN (SELECT ct.Name 
                      FROM Person.ContactType AS ct 
                      INNER JOIN Person.BusinessEntityContact AS bec 
                          ON bec.ContactTypeID = ct.ContactTypeID  
                      WHERE bec.PersonID = @ContactID)
            ELSE NULL 
        END;
    -- Get contact type
    SET @ContactType = 
        CASE 
            -- Check for employee
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'EM') 
            THEN 'Employee'
            -- Check for vendor
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'VC')
            THEN 'Vendor Contact'
            -- Check for store
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'SC')
            THEN 'Store Contact'
            -- Check for individual consumer
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'IN') 
            THEN 'Consumer'
             -- Check for general contact
            WHEN EXISTS(SELECT * FROM Person.Person AS p 
                        WHERE p.BusinessEntityID = @ContactID AND p.PersonType = 'GC') 
            THEN 'General Contact'
        END;
    -- Return the information to the caller
    IF @ContactID IS NOT NULL 
    BEGIN
        INSERT @retContactInformation
        SELECT @ContactID, @FirstName, @LastName, @JobTitle, @ContactType;
    END;
    RETURN;
END;
GO
代码订单2.表值函数

为什么要用表值函数
    看起来表值函数所做的事情和存储过程并无不同,但实际上还是有所差别。是因为表值函数可以被用于写入其他查询,而存储过程不行。此外,表值函数和Apply操作符联合使用可以极大的简化连接操作。

    如果存储过程符合下述条件的其中一个,可以考虑重写为表值函数。

存储过程逻辑非常简单,仅仅是一个Select语句,不用视图的原因仅仅是由于需要参数。

存储过程中没有更新操作。

存储过程中没有动态SQL。

存储过程中只返回一个结果集。

存储过程的主要目的是为了产生临时结果集,并将结果集存入临时表以供其他查询调用。

 

用户定义表值函数的问题
    表值函数与内联表值函数不同,内联表值函数在处理的过程中更像是一个视图,这意味着在查询优化阶段,内联表值函数可以参与查询优化器的优化,比如将筛选条件(Where)推到代数树的底部,这意味着可以先Where再Join,从而可以利用索引查找降低IO从而提升性能。

    让我们来看一个简单的例子。下面代码示例是一个简单的和表值函数做Join的例子:

    首先我们创建表值函数,分别为内联表值函数方式和表值函数方式,如代码清单3所示。

--创建表值行数
CREATE FUNCTION tvf_multi_Test ( )
RETURNS @SaleDetail TABLE ( ProductId INT )
AS
    BEGIN 
        INSERT  INTO @SaleDetail
                SELECT  ProductID
                FROM    Sales.SalesOrderHeader soh
                        INNER JOIN Sales.SalesOrderDetail sod ON soh.SalesOrderID = sod.SalesOrderID 
        RETURN 
    END
--创建内联表值函数
CREATE FUNCTION tvf_inline_Test ( )
RETURNS TABLE
AS
   RETURN
    SELECT  ProductID
    FROM    Sales.SalesOrderHeader soh
            INNER JOIN Sales.SalesOrderDetail sod ON soh.SalesOrderID = sod.SalesOrderID 
代码清单3.创建两种不同的函数

 

    现在,我们使用相同的查询,对这两个表值函数进行Join,代码如代码清单4所示。

--表值函数做Join
SELECT  c.personid ,
        Prod.Name ,
        COUNT(*) 'numer of unit'
FROM    Person.BusinessEntityContact c
        INNER JOIN dbo.tvf_multi_Test() tst ON c.personid = tst.ProductId
        INNER JOIN Production.Product prod ON tst.ProductId = prod.ProductID
GROUP BY c.personid ,
        Prod.Name 
 
--内联表值函数做Join
SELECT  c.personid ,
        Prod.Name ,
        COUNT(*) 'numer of unit'
FROM    Person.BusinessEntityContact c
        INNER JOIN dbo.tvf_inline_Test() tst ON c.personid = tst.ProductId
        INNER JOIN Production.Product prod ON tst.ProductId = prod.ProductID
GROUP BY c.personid ,
        Prod.Name 
代码清单4.表值函数和内联表值函数做Join

 

    执行的成本如图1所示。

image

图1.两种方式的成本

 

    从IO来看,很明显是选择了次优的执行计划,BusinessEntityContact选择了121317次查找,而不是一次扫描。而内联表函数能够正确知道扫描一次的成本远低于一次查找。

    那问题的根源是内联表值函数,对于SQL Server来说,和视图是一样的,这意味着内联表值函数可以参与到逻辑执行计划的代数运算(或者是代数树优化)中,这意味着内敛表可以进一步拆分(如图1所示,第二个内联表的查询,执行计划具体知道内敛表中是SalesOrderHeader表和SalesOrderDetail表,由于查询只选择了一列,所以执行计划优化直到可以无需扫描SalesOrderHeader表),对于内联表值函数来说,执行计划可以完整知道所涉及的表上的索引以及相关统计信息等元数据。

    另一方面,表值函数,如图1的第一部分所示,表值函数对整个执行计划来说是一个黑箱子,既不知道统计信息,也没有索引。执行计划中不知道表值函数所涉及的表(图1中为#AE4E5168这个临时表,而不是具体的表明),因此对整个执行计划来说该结果集SQL Server会假设返回的结果非常小,当表值函数返回的结果较多时(如本例所示),则会产生比较差的执行计划。

    因此综上所述,在表值函数返回结果极小时,对性能可能没有影响,但返回结果如果略多,则一定会影响执行计划的质量。

 

如何处理
    首先,在SQL Server中,我们要找出现存的和表值函数做Join的语句,通过挖掘执行计划,我们可以找出该类语句,使用的代码如代码清单5所示。

WITH XMLNAMESPACES('http://schemas.microsoft.com/sqlserver/2004/07/showplan' AS p)
SELECT  st.text,
        qp.query_plan
FROM    (
    SELECT  TOP 50 *
    FROM    sys.dm_exec_query_stats
    ORDER BY total_worker_time DESC
) AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qp.query_plan.exist('//p:RelOp[contains(@LogicalOp, "Join")]/*/p:RelOp[(@LogicalOp[.="Table-valued function"])]') = 1
代码清单5.从执行计划缓存中找出和表值函数做Join的查询

 

   结果如图2所示。

image

图2.执行计划缓存中已经存在的和表值函数做Join的查询

 

小结
    本文阐述了表值函数的概念,表值函数为何会影响性能以及在执行计划缓存中找出和表值函数做Join的查询。对于和表值函数做Apply或表值函数返回的行数非常小的查询,或许并不影响。但对于返回结果较多的表值函数做Join,则可能产生性能问题,因此如果有可能,把表值函数重写为内联表值函数或将表值函数的结果存入临时表再进行Join可提升性能。

 

本文转自CareySon博客园博客,原文链接:http://www.cnblogs.com/CareySon/p/4269897.html如需转载请自行联系原作者

相关文章
|
SQL 算法 Java
Mybatis-plus超详细讲解(2022)
MyBatis-Plus(简称 MP)是一个 MyBatis 的增强工具,在 MyBatis 的基础上只做增强不做改变,为简化开发、提高效率而生。 我们的愿景是成为 MyBatis 最好的搭档,就像 魂斗罗 中的 1P、2P,基友搭配,效率翻倍。
4189 1
|
5月前
|
缓存 PyTorch 算法框架/工具
AI Infra之模型显存管理分析
本文围绕某线上客户部署DeepSeek-R1满血版模型时进行多次压测后,发现显存占用一直上升,从未下降的现象,记录了排查过程。
470 41
AI Infra之模型显存管理分析
|
4月前
|
人工智能 自然语言处理 Java
腾讯云CodeBuddy Craft智能体测评|对话式编程太香了!🚀
本文分享了使用CodeBuddy等AI工具的编程体验,从对话式编程、代码补全到智能Review,大幅提升开发效率。Craft智能体重构优惠券模块仅需自然语言描述即可生成完整代码,DeepSeek V3实现流畅的数据分析链式操作补全,MCP协议快速复用跨团队组件。此外,AI还能优化遗留代码、生成单元测试、解决异常报错,甚至提供音乐可视化编程功能。文章还探讨了AI与开发者协作的边界,强调人类在业务逻辑和架构设计上的不可替代性,助力开发者从“搬砖”到“造火箭”。
216 0
腾讯云CodeBuddy Craft智能体测评|对话式编程太香了!🚀
|
弹性计算 缓存 监控
基于“日志审计应用”的 DNS 日志洞察实践
DNS 解析日志是一种记录 DNS 请求和响应的基础信息,监控 DNS 服务可以帮助用户识别网络活动并保持系统安全。日志审计服务支持采集 DNS 内网解析日志、公网权威解析日志、GTM 日志。理解 DNS 日志的字段含义,洞察 DNS 日志背后所代表的网络信息,既可以帮助发现和诊断 DNS 解析相关的问题,还可以检测和识别潜在的安全威胁。
8708 108
|
数据采集 存储 数据可视化
芒果tv数据采集与可视化实现
本文介绍了使用Python网络爬虫技术从芒果TV抓取电影信息(包括名称、播放量、评分等),并通过Matloplit库和Wordcloud库进行数据处理与可视化分析的研究项目。
401 0
芒果tv数据采集与可视化实现
|
11月前
|
监控 安全 测试技术
如何确保API对接过程中的数据安全?
确保API对接过程中的数据安全至关重要。最佳实践包括:使用HTTPS协议、强化身份验证和授权、数据加密、输入验证、访问控制、限流限速、日志记录和监控、安全测试、数据脱敏、错误处理、API网关、Web应用程序防火墙(WAF)、审计和合规性。这些措施能有效提升API的安全性,保护数据免受恶意攻击和泄露风险。
|
弹性计算 关系型数据库 MySQL
centos7 mysql安装及配置
本文详细介绍了在阿里云服务器ECS上通过yum源安装MySQL 8.0.12的过程,包括更新yum源、下载并安装MySQL源、解决安装过程中可能遇到的问题等步骤。此外,还介绍了如何启动MySQL服务、设置开机自启、配置登录密码、添加远程登录用户以及处理远程连接异常等问题。适合初学者参考,帮助快速搭建MySQL环境。
1082 8
centos7 mysql安装及配置
|
数据采集 人工智能 Serverless
AI 克隆声音,只需 3 分钟(附最全教程)
文章介绍了GPT-Sovits,一个开源的生成式语音模型,因其在声音克隆上的高质量和简易性而受到关注。阿里云函数计算(Function Compute)提供了一个快速托管GPT-Sovits的方法,让用户无需管理服务器即可体验和部署该模型。通过函数计算,用户可以便捷地搭建基于GPT-Sovits的文本到语音服务,并享受到按需付费和弹性扩展的云服务优势。此外,文章还列举了GPT-Sovits在教育、游戏、新能源等多个领域的应用场景,并提供了详细的步骤指导,帮助用户在阿里云上部署和体验GPT-Sovits模型。
36372 8
|
SQL 关系型数据库 MySQL
MySQL多条SQL语句合并实现
【5月更文挑战第11天】
460 0
|
安全
UICollectionView(一)——整体总结
前言 这几天有时间看了下UICollectionView的东西,才发觉它真的非常强大,很有必要好好学习学习。以前虽然用过几次,但没有系统的整理总结过。
1487 0

热门文章

最新文章