【问题标题】:Why does the inclusion of an XML column in a SELECT query have such a radically negative effect on query performance?为什么在 SELECT 查询中包含 XML 列会对查询性能产生如此大的负面影响?
【发布时间】:2013-11-18 20:40:20
【问题描述】:

几周以来,我一直在努力解决查询性能问题。在这一点上,我已经完全排除了查询中关于 JOIN 类型、索引、保持统计信息最新等方面的所有内容......但后来我偶然发现了一些东西。

一点背景。

有问题的表代表Record

Id INT PK
Name NVARCHAR(50)
Status INT FK 
Created DATETIME
Version NVARCHAR(10)
Data XML

在进行了一些性能基准测试后,我意识到在选择中包含最后一列远远超过索引、连接复杂性和网络考虑因素等因素 10 倍到 20 倍之间。

以下比较是在连接到 SQL Azure 的本地开发机器上的 SSMS 之间进行的。

SELECT Id FROM Records -- ~10 secs for 300,000 rows
SELECT Id, Name, Status, Created, Version FROM Records -- ~20 sec for 300,000 rows
SELECT * FROM Records -- ~350 sec for 300,000 rows

需要明确的是,我并没有对 xml 列(XML DML 或 XPath 查询)做任何疯狂的事情。只需简单地从选择中包含/排除它。

此时,我想我已经通过创建RecordLight 实体、NHibernate 地图和 MVC 控制器堆栈解决了我的问题,纯粹是为了在我们的应用中搜索和列出。

但我想了解为什么包含 XML 列会对查询性能产生如此负面的影响

【问题讨论】:

    标签: sql sql-server performance azure-sql-database xml-column


    【解决方案1】:

    要考虑的一件事是 XML 数据的字节大小。

    例如,如果您要连接到远程数据库服务器,则需要将所有数据下载到您的客户端(即使客户端是 SSMS)。

    例如,我在 blob 列中看到了同样的情况,其中包含 MB 的数据。

    如果你这样做:

    SELECT Id, LEFT(Data, 10) FROM Records
    

    你看到返回数据的时间是一样的吗?

    【讨论】:

      【解决方案2】:

      这与 XML 数据如何存储在 SQL Server 使用的文件中有关吗?其他大型数据类型(例如 BLOB)是否会出现类似的性能问题?如果 XML 列的实际内容(可能是一个非常大的文件)分布在其他文件中,那么我可以想象 SQL 将需要一些时间来“缝合”在一起。

      【讨论】:

        猜你喜欢
        • 2014-07-02
        • 2011-03-15
        • 1970-01-01
        • 2015-10-13
        • 1970-01-01
        • 2011-04-09
        • 2010-12-18
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多