DataAdapter.Fill性能异常

Question

我有两个数据库（DB1＆DB2：两个数据库是相同的，DB2是从DB1的备份创建的）。当我在这两个数据库上运行存储过程SP1时，它需要大约2秒钟才能在这两个数据库上为我提供输出（select语句）。

现在的问题是当我从服务中指向这些数据库并尝试使用DataAdapter.Fill方法时，它会在这两个数据库上始终给出不同的时间（在DB1上为54-63秒，在DB2上为42-44秒）。请注意，我使用同一服务来指向这些数据库，因此它不可能是服务的行为/性能。现在我的问题是：

这可能是什么原因？欢迎任何建议，我应该查看什么？

帮助信息:

1. 两个数据库位于不同的服务器上（配置相同），但在SQL Server Management Studio上执行SP在两个DB上花费的时间相同，因此我排除了DB server性能的可能性。网络延迟可能是一个因素，但很不可能，因为这两个servers位于同一网络上，实际上位于同一物理位置。这是我要检查的最后一个选项。

2. 一些其他服务正在DB1上使用SQLDependency。它们持续填充DataAdapter(s)，这可能是我的DataAdapter fill方法变慢的原因吗？（不太可能，因为我猜测）

如下所示是填充DataSet的代码：

PS：上面提到的时间是上图中突出显示的代码行的执行时间。

- Kylo Ren

---

@user1429080 不是的，SP 返回的数据和数据库中的整体数据是相同的，在我的本地环境中没有生产数据库场景，两者都是开发数据库。 - Kylo Ren

你的 select 查询中是否包含带参数的 where 子句？ - Ivan Stoev

通常情况下，当你在 SSMS（SQL Server Management Studio）内部运行很快，但在外部运行缓慢时，这表明可能存在参数嗅探问题。http://stackoverflow.com/search?q=parameter+sniffing - Ivan Stoev

@KyloRen 这只是为了测试目的，以帮助确定问题是否在数据库查询执行（第一部分 - ExecuteReader）或物化方面。如果大部分时间都在第一部分中，则应查看查询计划、参数嗅探等。 - Ivan Stoev

当您执行以下操作时会发生什么：

1. 交换两个服务器？从server2运行DB1，从server1运行DB2
2. 缩小数据库
3. 删除/重新创建所有索引

附加问题：当您从SQL Profiler中检查时，查询文本、计划和时间（CPU读取、持续时间等）之间是否有任何差异？ - Dexion

Answer 1

这听起来非常像一个查询计划问题。

Erland Sommerskog写了一篇关于这类问题的优秀文章，应用程序中慢，在SSMS中快？。

我的第一个猜测是 "默认设置"，但也可能是其他问题之一。

- TToni

---

这并不完全是我的问题。我的问题是两个数据库性能差异。 - Kylo Ren

@KyloRen：等等，所以你担心DB1和DB2之间的20%差异，而不是SSMS和ADO.NET之间的2000%差异？ - TToni

是的，这是一个大数据集，因此填充数据集需要时间，我无法弄清楚为什么两个数据库的性能不同？ - Kylo Ren

@KyloRen 首先，您应该在操作期间检查磁盘活动情况。如果需要从磁盘读取数据，则恢复的数据库在文件系统上可能更少碎片化，因此读取速度更快。如果磁盘上没有活动，则又涉及到不同的查询计划。提到的文章也有一些关于这方面的好资料。 - TToni

分段是一个值得关注的好建议。我没有检查它，因为在SSMS上两个数据库都表现出相同的性能？我这样做是正确的吗，还是分段可能会有这样的行为？ - Kylo Ren

一个 2 秒的响应与一个超过 40 秒的响应显然会做非常不同的事情。一个 2 秒的响应不太可能重复从磁盘读取。如果你在同一 SQL Server 实例上运行两个数据库，它们也可能使用不同数量的内存，在硬盘上占据不同的扇区。如果你有本地驱动器，根据信息所在位置、碎片化程度等因素，它们的性能也会有所不同。因此基本上你想要监视系统上发生了什么，并从中缩小范围到 SQL Server 上发生了什么。 - TToni

Answer 2

你尝试过不使用SQL.StoredProcedure，而只是将其作为一行SQL运行吗："exec dbname.dbo.storedprocname params"。

这需要更多的工作，因为您需要循环遍历参数并将其添加到字符串末尾，但它是一个SQL字符串，它不关心您在做什么，它不会在幕后做任何有趣的事情。如果出现问题，请尝试检查存储过程使用的数据库表上的索引等内容。

- Ian Martin

Answer 3

第一步 - 重建或重新组织索引。这通常是SQL Server中最常见的性能问题，很容易解决。有时候重新启动SQL Server也会有所帮助。

- Khadar