SQL递归函数触发嵌套层级超限（32层）问题排查

核心原因分析 #

你遇到的问题并非函数本身26次递归导致，大概率是以下情况之一：

• 无效数据触发异常递归：那条唯一的无效参考码可能格式异常（比如长度非27位、包含非数字字符），导致函数递归终止条件失效，进入近乎无限的递归，直到触达32层系统限制。
• 隐式递归调用链：Incoming_Invoices表可能存在触发器、计算列，或者你查询时用到的其他对象（视图/函数）也调用了fnCheckQRReference，形成嵌套调用，总层数超过32。
• 函数递归逻辑有漏洞：比如递归时未正确缩短处理的字符串长度，或终止条件判断错误，导致实际递归次数远超预期的26次。

分步排查方案 #

1. 单独测试无效数据：将那条无效的QR reference直接传入函数，确认是否触发同样错误。如果是，说明函数未正确处理异常格式数据，需在函数开头添加前置校验：先判断长度是否为27位、是否全为数字，不符合则直接返回无效，不进入递归逻辑。
2. 检查函数递归终止逻辑：查看函数代码，确认递归终止条件是否严谨。比如每次递归是否正确截断字符串的一位，是否在字符串长度为0时停止。若截断逻辑错误，会导致递归无限循环。
3. 排查表的依赖对象：用以下SQL查询Incoming_Invoices的相关触发器、计算列，以及函数的依赖关系，确认是否存在递归调用链：

-- 查询引用Incoming_Invoices的对象
SELECT * FROM sys.dm_sql_referencing_entities('dbo.Incoming_Invoices', 'OBJECT');
-- 查询fnCheckQRReference引用的对象，以及被哪些对象引用
SELECT * FROM sys.dm_sql_referenced_entities('dbo.fnCheckQRReference', 'OBJECT');
SELECT * FROM sys.dm_sql_referencing_entities('dbo.fnCheckQRReference', 'OBJECT');

4. 给函数添加递归保护：临时修改函数，增加递归层数计数，超过30层直接返回无效，既避免触发系统限制，也能验证是否为递归溢出导致的问题：

ALTER FUNCTION [dbo].[fnCheckQRReference]
(
    @QRReference VARCHAR(27),
    @RecursionLevel INT = 0
)
RETURNS BIT
AS
BEGIN
    -- 防止递归溢出
    IF @RecursionLevel > 30
        RETURN 0;

    -- 原有逻辑，递归调用时传入@RecursionLevel + 1
    -- 示例：SET @Result = dbo.fnCheckQRReference(@TruncatedString, @RecursionLevel + 1)
    -- ...
END

内容的提问来源于stack exchange，提问作者woodruf