SQL Server 2008中CTE实现Split函数和CLR实现Split函数性能差异有多大

在SQL Server 2008环境下，将单个逗号分隔的字符串拆分成多行数据，是ETL脚本和报表查询里经常遇到的需求。实现方式主要有两类：一类是用公用表表达式（CTE）写的纯T-SQL递归拆分，另一类是把.NET写的Split方法打包成程序集，开启CLR后在数据库里调用。两者写法不同，执行路径也不同，性能表现会随着数据规模出现明显分化。

一、CTE实现Split的原理与代码示例

CTE方式依靠递归查询，每次从字符串左边截取一段直到找不到逗号为止。它的好处是纯T-SQL，不需要配置CLR权限，部署到任何库都能直接跑。下面这段函数在SQL Server 2008中比较常用，用一个Anchor成员取第一个分隔项，再靠Recursive成员不断截断原串。

CREATE FUNCTION dbo.Split_CTE
(
    @str NVARCHAR(MAX),
    @sep NCHAR(1)
)
RETURNS @t TABLE (id INT IDENTITY, val NVARCHAR(MAX))
AS
BEGIN
    WITH cte (remainder, item) AS
    (
        SELECT
            @str AS remainder,
            CAST(LEFT(@str, CHARINDEX(@sep, @str + @sep) - 1) AS NVARCHAR(MAX)) AS item
        WHERE CHARINDEX(@sep, @str) > 0 OR LEN(@str) > 0
        UNION ALL
        SELECT
            SUBSTRING(remainder, CHARINDEX(@sep, remainder) + 1, LEN(remainder)) AS remainder,
            CAST(LEFT(SUBSTRING(remainder, CHARINDEX(@sep, remainder) + 1, LEN(remainder)),
                CHARINDEX(@sep, SUBSTRING(remainder, CHARINDEX(@sep, remainder) + 1, LEN(remainder)) + @sep) - 1) AS NVARCHAR(MAX)) AS item
        FROM cte
        WHERE CHARINDEX(@sep, remainder) > 0
    )
    INSERT INTO @t (val)
    SELECT item FROM cte
    RETURN
END

这段代码每次递归都要做CHARINDEX和SUBSTRING，字符串越长，递归层数越多，开销呈线性增长。对于几十条以内的短串，SQL引擎优化得不错，速度可以接受。但如果传入几千个字符、上百个分隔项，递归本身的栈管理和表达式重复计算就会拖慢整体响应。

另外CTE拆分依赖表变量返回，统计信息缺失，复杂查询里联表时优化器容易估错行数。它适合偶尔调用、数据量小的场景，比如配置项解析，不建议放进每天跑几百万次的批量任务。

二、CLR实现Split的原理与代码示例

CLR方式把拆分逻辑交给.NET的String.Split，利用托管代码在内存里直接生成数组再逐行吐出。SQL Server 2008需开启clr enabled，并把程序集设为SAFE或EXTERNAL_ACCESS。下面是用C#写的简单拆分函数。

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;

public class SplitFunctions
{
    [SqlFunction(FillRowMethodName = "FillRow", TableDefinition = "val nvarchar(4000)")]
    public static IEnumerable Split_CLR(SqlString str, SqlString sep)
    {
        if (str.IsNull || sep.IsNull) yield break;
        string[] items = str.Value.Split(sep.Value[0]);
        foreach (string s in items)
        {
            yield return s;
        }
    }

    public static void FillRow(Object obj, out SqlString val)
    {
        val = (string)obj;
    }
}

编译成dll后，在数据库执行CREATE ASSEMBLY和CREATE FUNCTION即可调用。因为.NET的字符串操作在堆上完成，且Split内部用指针级扫描，对比T-SQL里反复调用函数，大字符串拆分效率高出数倍。测试里拆一万项，CLR常比CTE快三到五倍。

不过启用CLR带来运维成本：要确认服务器策略允许，要管程序集签名，还要防备不安全的外部调用。在隔离严格的业务库里，开CLR需走审批，不如CTE即写即用。因此性能之外，落地难度也是选型一环。

三、性能对比与选型建议

我们在一台SQL Server 2008标准版上做了一组对照：同样拆一个含N个元素的串，循环执行一千次取平均毫秒。结果整理如下。

从表里能看出，十项左右时CTE反而略快，因为CLR有托管过程初始化和上下文切换的固定成本。过了百项，CLR的批量处理优势压过固定成本，差距随项数拉大。所以不要盲目认为CLR永远胜出，小数据量下CTE更轻。

实际选型时，先统计业务里Split的输入长度分布。若是页面传参解析几个ID，CTE函数放库里最省事。若是日志清洗要把长文本按逗号展开再关联，就值得专门启CLR并写好部署文档。两者并非互斥，可在同一库按场景分别保留。

四、常见误区与注意事项

有人把CTE递归层数上限当隐形坑，SQL Server默认最大递归一百层，拆超百项不写OPTION (MAXRECURSION 0)会报错。上面示例函数内部用表变量收集，外层调用若直接SELECT要补提示，否则生产环境一遇长串就抛异常。

错误示范：SELECT * FROM dbo.Split_CTE('a,b,c,...,z', ',') 超过百项直接终止查询。

对CLR来说，常见误区是认为SAFE程序集绝对无风险。其实一旦拆分逻辑里误用File或网络类型，就得升到EXTERNAL_ACCESS，攻击面扩大。另外CLR函数返回表时，FillRow方法类型要跟TableDefinition对齐，nvarchar长度不够会静默截断，排查起来很费时间。两类方案都建议先在小表做回归，再上主线任务。

SQL_Server_2008CTESplit_CLR修改时间：2026-08-09 23:42:45