2

我刚刚将一些随机导致错误的代码发布到生产环境中。我已经通过完全改变我进行查询的方式解决了这个问题。然而，它仍然困扰着我，我不知道是什么导致了问题，所以想知道是否有人可能知道答案。我在存储过程中有以下查询。我不是在寻找关于使用嵌套函数调用和类似的东西进行查询不是一个好习惯的评论:-)。只是真的想找出为什么它不能始终如一地工作。随机查询中的函数将返回一个非数字值并导致连接错误。但是，如果我立即重新运行查询，它工作正常。

SELECT      cscsf.cloud_server_current_software_firewall_id,
                dbo.fn_GetCustomerFriendlyFromRuleName(cscsf.rule_name, np.policy_name) as rule_name,
                cscsf.rule_action,
                cscsf.rule_direction,
                cscsf.source_address,
                cscsf.source_mask,
                cscsf.destination_address,
                cscsf.destination_mask,
                cscsf.protocol,
                cscsf.port_or_port_range,
                cscsf.created_date_utc,
                cscsf.created_by
    FROM        CLOUD_SERVER_CURRENT_SOFTWARE_FIREWALL cscsf
    LEFT JOIN   CLOUD_SERVER cs
    ON          cscsf.cloud_server_id = cs.cloud_server_id
    LEFT JOIN   CLOUD_ACCOUNT cla
    ON          cs.cloud_account_id = cla.cloud_account_id
    LEFT JOIN   CONFIGURATION co
    ON          cla.configuration_id = co.configuration_id
    LEFT JOIN   DEDICATED_ACCOUNT da
    ON          co.dedicated_account_id = da.dedicated_account_id
    LEFT JOIN   CORE_ACCOUNT ca
    ON          da.core_account_number = ca.core_account_id
    LEFT JOIN   NETWORK_POLICY np 
    ON          np.network_policy_id = (select dbo.fn_GetIDFromRuleName(cscsf.rule_name))
    WHERE       cs.cloud_server_id = @cloud_server_id
    AND         cs.current_software_firewall_confg_guid = cscsf.config_guid
    AND         ca.core_account_id IS NOT NULL
    ORDER BY    cscsf.rule_direction, cscsf.cloud_server_current_software_firewall_id

如果你注意到加入

ON          np.network_policy_id = (select dbo.fn_GetIDFromRuleName(cscsf.rule_name))

调用一个函数。

这是该功能：

ALTER FUNCTION [dbo].[fn_GetIDFromRuleName]
(
    @rule_name              varchar(100)
)
RETURNS varchar(12)
AS
BEGIN
    DECLARE     @value      varchar(12)

        SET @value = dbo.fn_SplitGetNthRow(@rule_name, '-', 2)
        SET @value = dbo.fn_SplitGetNthRow(@value, '_', 2)
        SET @value = dbo.fn_SplitGetNthRow(@value, '-', 1)

    RETURN      @value
END

然后调用此函数：

ALTER FUNCTION [dbo].[fn_SplitGetNthRow]
(
    @sInputList     varchar(MAX),
    @sDelimiter     varchar(10) = ',',
    @sRowNumber     int = 1
)
RETURNS varchar(MAX)
AS
BEGIN
    DECLARE     @value      varchar(MAX)

    SELECT      @value = data_split.item
                        FROM
                        (
                            SELECT *, ROW_NUMBER() OVER (ORDER BY (SELECT 1)) as row_num FROM dbo.fn_Split(@sInputList, @sDelimiter)
                        ) AS data_split
                        WHERE
                        data_split.row_num = @sRowNumber

    IF          @value IS NULL
        SET     @value = ''

    RETURN      @value  
END

最后调用这个函数：

ALTER FUNCTION [dbo].[fn_Split] (
    @sInputList VARCHAR(MAX),
    @sDelimiter VARCHAR(10) = ','
) RETURNS @List TABLE (item VARCHAR(MAX))
BEGIN
    DECLARE @sItem VARCHAR(MAX)
    WHILE CHARINDEX(@sDelimiter,@sInputList,0) <> 0
        BEGIN
            SELECT @sItem=RTRIM(LTRIM(SUBSTRING(@sInputList,1,CHARINDEX(@sDelimiter,@sInputList,0)-1))), @sInputList=RTRIM(LTRIM(SUBSTRING(@sInputList,CHARINDEX(@sDelimiter,@sInputList,0)+LEN(@sDelimiter),LEN(@sInputList))))
            IF LEN(@sItem) > 0
                INSERT INTO @List SELECT @sItem
        END

    IF LEN(@sInputList) > 0
        INSERT INTO @List SELECT @sInputList -- Put the last item in
    RETURN
END
4

1 回答 1

7

它“随机”返回不同内容的原因与 SQL Server 如何优化查询以及它们在哪里短路有关。

解决问题的一种方法是更改​​ fn_GetIDFromRuleName 的返回值：

return (case when isnumeric(@value) then @value end)

或者，更改连接条件：

on np.network_policy_id = (select case when isnumeric(dbo.fn_GetIDFromRuleName(cscsf.rule_name)) = 1)
                                       then dbo.fn_GetIDFromRuleName(cscsf.rule_name) end)

潜在的问题是评估的顺序。“case”语句解决问题的原因是它在转换之前检查数值，并且SQL Server 保证 case 语句中的计算顺序。需要注意的是，在转换像“6e07”或“1.23”这样的数字时仍然会遇到问题，这些数字是数字，但不是整数。

为什么有时会起作用？好吧，显然查询执行计划正在发生变化，无论是静态的还是动态的。失败的情况可能在 WHERE 条件排除的行上。为什么它会尝试进行转换？问题是转换发生在哪里。

转换发生的位置取决于查询计划。反过来，这可能取决于读取相关表 cscf 的时间。如果它已经在成员中，那么它可能会被读取并尝试转换为查询中的第一步。然后你会得到错误。在另一种情况下，另一个表可能是过滤器，并且在转换之前删除了行。

无论如何，我的建议是：

  • 永远不要在查询中进行隐式转换。
  • 使用 case 语句进行显式转换。
  • 不要依赖 WHERE 子句来过滤数据以进行转换。使用 case 语句。
于 2012-09-05T18:29:47.347 回答