XML AUTO函数与T-SQL命令对比 作为一个DBA,我倾向于关注性能方面的问题,因此我要确定使用XML(扩展标记语言)不会对性能产生影响。在本文中,我会通过比较XML AUTO功能和标准的T-SQL命令来显示性能上的差异。在测试过程中,我仅会涉及到XML AUTO功能的一个比较小的基础部分,同时我还建议大家在自己的环境中测试将要使用的XML功能。 测试环境描述 为了测试,我已经创建了一张表,往里插入了10000条记录,描述如下: 此表包含以下记录: select * from Employes XML Auto处理大量数据 我在刚才那张表中使用如下查询语句,以……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
XML AUTO函数与T-SQL命令对比
作为一个DBA,我倾向于关注性能方面的问题,因此我要确定使用XML(扩展标记语言)不会对性能产生影响。在本文中,我会通过比较XML AUTO功能和标准的T-SQL命令来显示性能上的差异。在测试过程中,我仅会涉及到XML AUTO功能的一个比较小的基础部分,同时我还建议大家在自己的环境中测试将要使用的XML功能。
测试环境描述
为了测试,我已经创建了一张表,往里插入了10000条记录,描述如下:
此表包含以下记录:
select * from Employes
XML Auto处理大量数据
我在刚才那张表中使用如下查询语句,以一个标准的查询开始,并且之后每次都向命令上加上更多的XML结构:
SELECT * FROM Employes Go SELECT * FROM Employes FOR XML AUTO go SELECT * FROM Employes FOR XML AUTO, TYPE go SELECT * FROM Employes FOR XML AUTO, TYPE, ELEMENTS go SELECT * FROM Employes FOR XML AUTO, TYPE, ELEMENTS, ROOT go |
我使用SQL Profiler来监控这些命令。我发现Duration列在SQL Profiler中是不准确的。当Query Analyzer仍在处理结果时,执行过了的XML命令已经在Profiler中显示了。因此,我将会忽视此列,并查找其它的资源:CPU和I/O。下面是对五个命令执行三次的监控结果:
这看起来似乎T-SQL查询比其它方式执行的效果要好一些。XML AUTO的XML查询产生同样的I/O,却多使用了八倍的CPU资源。复杂的XML命令比T-SQL命令消耗了超过80倍的读取操作,同时还有许多写操作和上面的六倍的CPU。
使用以下命令来分析I/O统计:
Table 'Employes'. Scan count 1, logical reads 8247, physical reads 0, read-ahead reads 7520, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Employes'. Scan count 1, logical reads 8247, physical reads 0, read-ahead reads 4221, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Employes'. Scan count 1, logical reads 8247, physical reads 500, read-ahead reads 2586, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Worktable'. Scan count 0, logical reads 7, physical reads 1, read-ahead reads 0, lob logical reads 229128, lob physical reads 285, lob read-ahead reads 43082. Table 'Employes'. Scan count 1, logical reads 8247, physical reads 0, read-ahead reads 1394, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Worktable'. Scan count 0, logical reads 7, physical reads 0, read-ahead reads 0, lob logical reads 230170, lob physical reads 0, lob read-ahead reads 43115. Table 'Employes'. Scan count 1, logical reads 8247, physical reads 125, read-ahead reads 3835, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Worktable'. Scan count 0, logical reads 7, physical reads 0, read-ahead reads 0, lob logical reads 230170, lob physical reads 140, lob read-ahead reads 43115. |
翻译
相关推荐
-
OpenWorld18大会:Ellison宣布数据库的搜寻和破坏任务
在旧金山举行的甲骨文OpenWorld 2018大会中,甲骨文首席技术官(CTO)兼创始人Larry Elli […]
-
ObjectRocket着力发展Azure MongoDB服务
MongoDB吸引了微软公司的注意力,微软公司计划针对运行于该公司2017年发布的Azure Cosmos D […]
-
Notre Dame对云端SQL Server性能基准的探索实践
确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。
-
DBA必须掌握的数据库恢复管理技术
如果没有备份副本,数据库管理员就无法还原数据库,所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是,对我来说,这种逻辑一直是错误的。