做了一个简单的xml data type的update性能测试。
在自己的pc上，建了一个表create table xml_test (xcol xml,Tcol nvarchar(50),id int identity(1,1))
插入10万条数据
declare @i int
set @i =0
while(@i<100000)
begin
insert xml_test
values (‘”this is a test”‘,’this is a test’)
set @i=@i+1
end
更新的两种情况：
Case 1: xml update
update
xml_test
set
xcol.modify(‘ replace value of (//Body/text())[1]
with “hello world” ‘)
Case 2: nvarchar update
update
xml_test
set
Tcol =’hello world ‘
同一台机器，同样的时间段，所以同样的负载，甚至是同一张表里，差别仅仅是列的数据类型的不同。
结果是Case1每次更新新的字符串时都要10秒以上，即使是重复运行Case1,第二次也总需要6秒。
而Case2则在3-4秒就完成了，重复运行则在一秒以下。
由于前述的理由，造成这个差别的就是xml data type和nvarchar data type的差别，而由于最基本操作都是字符串的更新，并且更新到的字符串也是一致的，所以有理由相信这个差别是定位所需要的时间差。
这就是xml结构的代价。应该说，这个代价还是很大的。我曾经想过的利用xml 数据类型来做动态的数据存放的方法，性能上看是不可行的。
这个想法，具体来说就是利用一个做数据字典用途的表：TableStructure(ID,TableName,TableColumns (xml type)),则可以把每个存放具体数据的表都定义为TableName(ID,Content(xml type)),然后利用xml数据的query,modify方法来操作Content里面的具体字段的内容。付出的是定位需要的时间，得到的是全动态的数据存放。由于xml的定位是动态的，即query,modify方法都可以接受参数，传入的XQuery的列名和路径都可以动态配置，那么理论上可以把一些基本的逻辑写成工具sp,实现具体功能的时候则可以调用工具sp+xpath参数。目标是：把功能的实现代码里更多的内容参数化– 比如对id=x的某记录的y字段的更新，不仅传x作为参数，甚至字段id和y也是参数。这样的话，只需要很少的sp和function就可以做很多事情，并且，它将更灵活，也可以把更多的东西可以拿来做configure。