SQLSERVER2008中CTE的Split与CLR的性能比较 <转>
之前曾有一篇POST是关于用CTE实现Split,这种方法已经比传统的方法高效了。今天我们就这个方法与CLR实现的Split做比较。在CLR实现Split函数的确很简单,dotnet framework本身就有这个function了。 我们新建一个c#-数据库工程,然后建立一个用户自定义函数,Co
之前曾有一篇POST是关于用CTE实现Split,这种方法已经比传统的方法高效了。今天我们就这个方法与CLR实现的Split做比较。在CLR实现Split函数的确很简单,dotnet framework本身就有这个function了。
我们新建一个c#-数据库工程,然后建立一个用户自定义函数,Code像这样:
1: ///
2: /// SQLs the array.
3: ///
4: /// The STR.
5: /// The delimiter.
6: ///
7: /// 1/8/2010 2:41 PM author: v-pliu
8: [SqlFunction(Name = "CLR_Split",
9: FillRowMethodName = "FillRow",
10: TableDefinition = "id nvarchar(10)")]
11:
12: public static IEnumerable SqlArray(SqlString str, SqlChars delimiter)
13: {
14: if (delimiter.Length == 0)
15: return new string[1] { str.Value };
16: return str.Value.Split(delimiter[0]);
17: }
18:
19: ///
20: /// Fills the row.
21: ///
22: /// The row.
23: /// The STR.
24: /// 1/8/2010 2:41 PM author: v-pliu
25: public static void FillRow(object row, out SqlString str)
26: {
27: str = new SqlString((string)row);
28: }
然后编译,部署一切OK后,在SSMS中执行以下测试T-sql:
1: DECLARE @array VARCHAR(max)
2: 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'
3: SELECT id FROM dbo.CLR_Split(@array,',')
我们来看它的Client Statistic:
接着我们执行测试T-sql使用相同的array:
1: DECLARE @array VARCHAR(max)
2: 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'
3: 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
即可启用 解释: 备注 clr enabled 选项是一个高级选项。如果使用 sp_configure 系统存储过程来更改该设置,则只有在 show advanced options 设置为 1 时才能更改 clr enabled。该设置在运行 sp_configure 后立即生效。不需要重新启动 SQL Server 实例。
"
配置选项 '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 上执行程序集。
注意:
运行 RECONFIGURE 时,clr enabled 选项的运行值将从 1 改为 0,所有包含用户程序集的应用程序域将立即被卸载