SQLSERVER2008中CTE的Split与CLR的性能比较 <转>

 

     之前曾有一篇POST是关于用CTE实现Split，这种方法已经比传统的方法高效了。今天我们就这个方法与CLR实现的Split做比较。在CLR实现Split函数的确很简单，dotnet framework本身就有这个function了。
    我们新建一个c#-数据库工程，然后建立一个用户自定义函数,Code像这样:

    /// <summary>
    /// SQLs the array.
    /// </summary>
    /// <param name="str">The STR.</param>
    /// <param name="delimiter">The delimiter.</param>
    /// <returns></returns>
    /// 1/8/2010  2:41 PM   author: v-pliu
    [SqlFunction(Name = "CLR_Split",
    FillRowMethodName = "FillRow",
    TableDefinition = "id nvarchar(10)")]

    public static IEnumerable SqlArray(SqlString str, SqlChars delimiter)
    {
        if (delimiter.Length == 0)
            return new string[1] { str.Value };
        return str.Value.Split(delimiter[0]);
    }

    /// <summary>
    /// Fills the row.
    /// </summary>
    /// <param name="row">The row.</param>
    /// <param name="str">The STR.</param>
    /// 1/8/2010  2:41 PM   author: v-pliu
    public static void FillRow(object row, out SqlString str)
    {
        str = new SqlString((string)row);
    }

然后编译,部署一切OK后，在SSMS中执行以下测试T-sql:

DECLARE @array VARCHAR(max)
SET  @array = '39,15,93,68,64,43,90,58,39,9,26,26,89,47,91,57,98,16,55,9,63,29,69,16,41,76,34,60,68,64,61,53,32,30,11,72,57,63,36,43,22,14,60,38,24,5,66,26,26,21,22,99,55,18,7,10,46,76,27,88,9,29,89,75,48,72,94,59,35,19,0,35,79,11,87,49,68,30,91,35,9,7,34,47,41,61,98,13,22,1,26,80,35,48,34,92,24,85,90,51'
SELECT id FROM dbo.CLR_Split(@array,',')

 

我们来看它的Client Statistic:

接着我们执行测试T-sql使用相同的array:

DECLARE @array VARCHAR(max)
SET  @array = '39,15,93,68,64,43,90,58,39,9,26,26,89,47,91,57,98,16,55,9,63,29,69,16,41,76,34,60,68,64,61,53,32,30,11,72,57,63,36,43,22,14,60,38,24,5,66,26,26,21,22,99,55,18,7,10,46,76,27,88,9,29,89,75,48,72,94,59,35,19,0,35,79,11,87,49,68,30,91,35,9,7,34,47,41,61,98,13,22,1,26,80,35,48,34,92,24,85,90,51'
SELECT item FROM strToTable(@array,',')

 

CTE实现的Split function的Client statistic:

通过对比，你可以发现CLR的performance略高于CTE方式，原因在于CLR方式有Cache功能，并且把一个复杂的运算放到程序里比DataBase里更加高效。

 

您还可以参考：

Split string in SQL Server 2005+ CLR vs. T-SQL

 

Author:Petter Liu    http://wintersun.cnblogs.com/

希望这篇POST对您有帮助。

出现禁止在 .NET Framework 中执行用户代码。启用 "clr enabled" 配置选项错误。

解决方法：查询分析器中运行如下代码即可：

exec sp_configure 'show advanced options', '1';
go
reconfigure;
go
exec sp_configure 'clr enabled', '1'
go
reconfigure;
exec sp_configure 'show advanced options', '1';
go

 

即可启用
"
配置选项 'show advanced options' 已从 0 更改为 1。请运行 RECONFIGURE 语句进行安装。
配置选项 'clr enabled' 已从 0 更改为 1。请运行 RECONFIGURE 语句进行安装。
配置选项 'show advanced options' 已从 1 更改为 1。请运行 RECONFIGURE 语句进行安装。
"
 

解释:
sp_configure [ [ @configname = ] 'option_name'
      [ , [ @configvalue = ] 'value' ] ]
 

备注
使用 sp_configure 可以显示或更改服务器级别的设置。若要更改数据库级别设置，请使用 ALTER DATABASE。若要更改仅影响当前用户会话的设置，请使用 SET 语句。
更新运行的配置值
为 option 指定新 value 时，结果集的 config_value 列中将显示该值。该值最初与 run_value 列中的值不同，后者显示当前运行的配置值。若要更新 run_value 列中的运行配置值，系统管理员必须运行 RECONFIGURE 或 RECONFIGURE WITH OVERRIDE。
RECONFIGURE 和 RECONFIGURE WITH OVERRIDE 对每个配置选项都有效。但是，基本 RECONFIGURE 语句会拒绝处于合理范围之外或可能导致选项冲突的任何选项值。例如，如果 recovery interval 的值大于 60 分钟，或 affinity mask 的值与 affinity I/O mask 的值重叠，则 RECONFIGURE 会生成错误。与此相反，RECONFIGURE WITH OVERRIDE 则接受具有正确数据类型的任何选项值，并使用指定的值强制进行重新配置。
有些配置选项（例如 affinity mask 和 recovery interval）被指定为高级选项。默认情况下，无法查看和更改这些选项。若要使这些选项可用，请将 Show Advanced Options 配置选项设置为 1。
使用 clr enabled 选项可以指定 Microsoft SQL Server 是否可以运行用户程序集。clr enabled 选项提供下列值。
值 说明
0
 不允许在 SQL Server 上执行程序集。
 
1
 允许在 SQL Server 上执行程序集。
 

clr enabled 选项是一个高级选项。如果使用 sp_configure 系统存储过程来更改该设置，则只有在 show advanced options 设置为 1 时才能更改 clr enabled。该设置在运行 sp_configure 后立即生效。不需要重新启动 SQL Server 实例。
注意：
运行 RECONFIGURE 时，clr enabled 选项的运行值将从 1 改为 0，所有包含用户程序集的应用程序域将立即被卸载

 原文地址:http://www.cnblogs.com/wintersun/archive/2010/01/08/1642265.html