哇，这问题真的太反直觉了！我之前在优化老系统的标量UDF时也碰到过类似的诡异情况，当时折腾了好半天，先给你拆解下可能的原因，再给几个靠谱的解决办法：

可能的原因分析 #

首先可以排除你提到的参数嗅探——参数嗅探影响的是执行计划的选择，而不是编译时间本身。真正的问题大概率出在SQL Server对标量UDF的编译路径选择上：

• SQL Server的查询优化器在处理标量UDF时，会根据函数的分支结构、表达式复杂度、是否有循环等特征，选择不同的编译策略。你之前保留的那个死循环（WHILE 1=2）虽然完全不可达，但它可能让优化器把函数判定为「带有循环结构的简单函数」，反而触发了更轻量的编译路径，跳过了某些深层的表达式合并/优化检查；
• 当你移除这段代码后，优化器可能会尝试对函数里的多段字符串操作做更复杂的常量传播、表达式折叠等优化，反而因为这些过度的优化步骤导致编译时间暴涨——说起来有点扯，但SQL Server的优化器偶尔会在这种看似简单的标量函数上“想太多”，反而翻车。

靠谱的解决办法 #

1. 给UDF加上WITH SCHEMABINDING（最快速的临时修复） #

给函数绑定架构后，SQL Server会提前缓存函数的编译计划，而且优化器对绑定架构的UDF的编译逻辑会更稳定，不会因为函数内容的微小变化（比如移除不可达代码）触发完全不同的编译路径。

修改后的函数示例：

CREATE FUNCTION [dbo].[TestCleanString] (
    @psActualName VARCHAR(100)
)
RETURNS VARCHAR(100)
WITH RETURNS NULL ON NULL INPUT, SCHEMABINDING -- 新增SCHEMABINDING
AS
BEGIN
    DECLARE @sName VARCHAR(100) = '';

    SET @sName = UPPER(LTRIM(RTRIM(ISNULL(@psActualName, ''))));

    IF LEN(@sName) = 0 RETURN '';

    IF RIGHT(@sName, 3) IN(' JR',' SR') SET @sName =  SUBSTRING(@sName , 1, len(@sName )-3) 

    IF RIGHT(@sName, 1) IN('S','Z') --ends with S or Z
        AND PATINDEX('%[^SZ]%', @sName) > 0 --has at least one non S or Z
        set @sName = SUBSTRING(@sName, 1, LEN(@sName) - (PATINDEX('%[^SZ]%', REVERSE(@sName)) -1)) --remove however many S's and Z's are at the end


    IF LEFT(@sName, 3) = 'MAC' SET @sName = 'MC' + SUBSTRING(@sName, 4, LEN(@sName));                   --change initial MAC to MC
    IF LEFT(@sName, 2) = 'PF' SET @sName = 'F' + SUBSTRING(@sName, 3, LEN(@sName));                     --initial PF to F

    IF RIGHT(@sName, 2) = 'IX' SET @sName = SUBSTRING(@sName, 1, LEN(@sName) - 2) + 'IC';               --trailing IX -> IC
    IF RIGHT(@sName, 2) = 'EX' SET @sName = SUBSTRING(@sName, 1, LEN(@sName) - 2) + 'EC';               --trailing EX -> EC
    IF RIGHT(@sName, 2) IN('YE','EE','IE') SET @sName = SUBSTRING(@sName, 1, LEN(@sName) - 2) + 'Y';    --trailing YE EE IE -> Y
    IF RIGHT(@sName, 2) IN('NT','ND') SELECT @sName = SUBSTRING(@sName, 1, LEN(@sName) - 2) + 'N';      --trailing NT ND -> N 
    IF RIGHT(@sName, 2) IN('DT','RT', 'RD') SELECT @sName = SUBSTRING(@sName, 1, LEN(@sName) - 2) + 'D';--trailing DT RT RD -> D 

    set @sName = REPLACE(@sName, 'WR','R')

    return @sName
END

2. 把标量UDF改成内联表值函数（iTVF）（长期最优方案） #

标量UDF在SQL Server里一直是性能重灾区，尤其是编译和执行时的开销。换成内联表值函数是现在官方推荐的优化方式，优化器可以直接把iTVF的逻辑展开到调用它的查询中，编译时间会大幅降低，执行性能也会提升很多。

改写后的iTVF示例：

CREATE FUNCTION [dbo].[TestCleanString_ITVF] (
    @psActualName VARCHAR(100)
)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
WITH NameCTE AS (
    -- 初始清洗：去空、转大写、去前后空格
    SELECT 
        UPPER(LTRIM(RTRIM(ISNULL(@psActualName, '')))) AS sName
),
TrimSuffixCTE AS (
    -- 移除JR/SR后缀
    SELECT
        CASE 
            WHEN LEN(sName) = 0 THEN ''
            WHEN RIGHT(sName, 3) IN(' JR',' SR') THEN SUBSTRING(sName, 1, LEN(sName)-3)
            ELSE sName
        END AS sName
    FROM NameCTE
),
TrimSZCTE AS (
    -- 移除末尾连续的S/Z
    SELECT
        CASE
            WHEN RIGHT(sName, 1) IN('S','Z') AND PATINDEX('%[^SZ]%', sName) > 0
            THEN SUBSTRING(sName, 1, LEN(sName) - (PATINDEX('%[^SZ]%', REVERSE(sName)) -1))
            ELSE sName
        END AS sName
    FROM TrimSuffixCTE
),
PrefixFixCTE AS (
    -- 修正前缀MAC→MC、PF→F
    SELECT
        CASE
            WHEN LEFT(sName, 3) = 'MAC' THEN 'MC' + SUBSTRING(sName, 4, LEN(sName))
            WHEN LEFT(sName, 2) = 'PF' THEN 'F' + SUBSTRING(sName, 3, LEN(sName))
            ELSE sName
        END AS sName
    FROM TrimSZCTE
),
SuffixFixCTE AS (
    -- 修正各种后缀
    SELECT
        CASE
            WHEN RIGHT(sName, 2) = 'IX' THEN SUBSTRING(sName, 1, LEN(sName)-2) + 'IC'
            WHEN RIGHT(sName, 2) = 'EX' THEN SUBSTRING(sName, 1, LEN(sName)-2) + 'EC'
            WHEN RIGHT(sName, 2) IN('YE','EE','IE') THEN SUBSTRING(sName, 1, LEN(sName)-2) + 'Y'
            WHEN RIGHT(sName, 2) IN('NT','ND') THEN SUBSTRING(sName, 1, LEN(sName)-2) + 'N'
            WHEN RIGHT(sName, 2) IN('DT','RT', 'RD') THEN SUBSTRING(sName, 1, LEN(sName)-2) + 'D'
            ELSE sName
        END AS sName
    FROM PrefixFixCTE
),
FinalFixCTE AS (
    -- 替换WR→R
    SELECT
        REPLACE(sName, 'WR','R') AS CleanedName
    FROM SuffixFixCTE
)
SELECT CleanedName FROM FinalFixCTE;

调用方式也很简单：SELECT CleanedName FROM dbo.TestCleanString_ITVF('SMITH JR')

3. 用轻量占位符替代原来的死循环（临时过渡方案） #

如果你暂时不想重构函数，可以用一个更优雅的“无意义但不执行”的语句替代原来的死循环，既不影响逻辑，又能保持原来的编译路径：

CREATE FUNCTION [dbo].[TestCleanString] (
    @psActualName VARCHAR(100)
)
RETURNS VARCHAR(100)
WITH RETURNS NULL ON NULL INPUT
AS
BEGIN
    -- 原有逻辑完全不变...

    return @sName

    -- 替代死循环的轻量占位符，完全不执行但能稳定编译路径
    IF 1=0 BEGIN
        SET @sName = @sName;
    END
END

4. 开启SQL Server 2019+的标量UDF内联特性 #

如果你的SQL Server版本是2019及以上，默认已经开启了scalar udf inlining特性，它会自动把符合条件的标量UDF内联成表达式，和iTVF的效果类似，能大幅降低编译时间。可以用下面的语句检查是否开启：

SELECT name, value_in_use 
FROM sys.configurations 
WHERE name = 'scalar udf inlining';

如果没开启，执行下面的命令开启：

sp_configure 'show advanced options', 1;
RECONFIGURE;
sp_configure 'scalar udf inlining', 1;
RECONFIGURE;

总结 #

• 优先推荐改成内联表值函数，这是解决标量UDF性能和编译问题的长期最优解；
• 临时修复可以加SCHEMABINDING或者用轻量占位符；
• 你的问题和参数嗅探无关，不用在这上面浪费时间。

如果测试后还有新的情况，随时补充细节我再帮你分析！