0

几个星期以来，我一直在努力解决查询性能问题。在这一点上，我已经从 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 Map 和 MVC 控制器堆栈解决了我的问题，纯粹是为了在我们的应用程序中搜索和列出。

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

4

2 回答 2

2

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

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

例如，对于包含 MB 数据的 blob 列，我已经看到了同样的情况。

如果您执行以下操作：

SELECT Id, LEFT(Data, 10) FROM Records

您看到返回数据的时间是否相同？

于 2013-11-07T09:22:48.950 回答
1

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

于 2013-11-07T09:21:34.547 回答