SQL Server 2019兼容级别150下标量函数触发内存不足问题咨询

• 核心触发点是SQL Server 2019（兼容级别150）新增的**标量UDF内联（Scalar UDF Inlining）**特性，该特性默认开启，会将标量函数的逻辑拆解嵌入主查询执行计划，代替传统逐行调用函数的执行模式，本意是优化性能，但早期版本存在大量边界场景的bug。
• 你的函数存在多个包含动态变量计算（4 + @DECIMALS这类变量参与长度判断）的IF分支，优化器做内联转换时需要枚举所有可能的执行路径，该场景下优化器出现了路径过度展开、内存泄漏问题，随着分支数量增加，内存占用持续升高，最终触发默认资源池内存不足报错。
• 兼容级别下调到140后问题消失，是因为SQL Server 2017没有标量UDF内联特性，函数仍按传统标量调用模式执行，不会触发优化器的这个bug。
• Azure SQL上运行正常，是因为Azure SQL的补丁迭代速度远快于本地SQL Server，该内联相关的bug早已被修复，而你的本地SQL Server 2019未安装对应累积更新。

• 及时安装最新累积更新：SQL Server 2019 RTM版本的标量UDF内联存在大量内存泄漏、执行逻辑错误的bug，截止最新CU已修复绝大多数此类问题，安装累积更新是规避这类问题性价比最高的方案。
• 手动关闭问题函数的内联属性：不需要调整整个库的兼容级别，只需要在函数定义中添加WITH INLINE = OFF选项，即可单独关闭该函数的内联能力，直接规避内联相关bug。
• 避免编写过多分散的分支逻辑：尤其是分支判断条件中包含动态变量计算、字符串长度动态判断的逻辑，会大幅提升优化器内联转换时的复杂度，容易触发边界bug。同类格式转换逻辑可以优先用内置FORMAT函数、动态拼接逻辑简化，减少分支数量。
• 复杂逻辑优先改用内联表值函数（iTVF）：内联表值函数的执行模式更稳定，不会触发标量UDF内联的相关问题，执行效率也优于普通标量函数。
• 开启内联前做好测试：如果需要使用标量UDF内联特性，上线前需要对现有自定义标量函数做全量回归测试，避免触发未被修复的边界bug。

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