问选择简单表上的低性能语句

EN

在查询运行时监视它，看看它是被阻塞了还是在等待资源。如果您在监视数据库和客户端机器时很难看出瓶颈所在，我建议您运行几个简单的测试，以帮助确定您应该集中精力的地方。理想情况下，在没有其他重要活动和冷缓存的情况下运行测试。

首先，在数据库服务器上运行查询并丢弃结果。这可以通过SSMS使用丢弃结果选项(查询->查询选项->结果->网格->执行后丢弃结果)来完成。或者，使用下面这样的Powershell脚本：

$connectionString = "Data Source=YourServer;Initial Catalog=YourDatabase;Integrated Security=SSPI;Application Name=Performance Test";
$connection = New-Object System.Data.SqlClient.SqlConnection($connectionString);
$command = New-Object System.Data.SqlClient.SqlCommand("SELECT * FROM Dim_TFS_File;", $connection);
$command.CommandTimeout = 0;
$sw = [System.Diagnostics.Stopwatch]::StartNew();
$connection.Open();
[void]$command.ExecuteNonQuery(); #this will discard returned results
$connection.Close();
$sw.Stop();
Write-Host "Done. Elapsed time is $($sw.Elapsed.ToString())";

在客户端机器上重复上述测试。经过的时间差反映了数据传输网络的开销。如果客户端机器测试比应用程序快得多，请集中精力编写应用程序代码。否则，请仔细查看数据库和网络。下面是一些可能有助于纠正性能问题的随机注释。

这个简单的查询可能会执行完整的聚集索引扫描。数据库服务器上的限制性能因素将是：

CPU:这个单线程查询的线程将受到单个CPU核心的限制。

存储: Server存储引擎将在大扫描期间使用预读读取异步获取数据，以便数据在查询需要时已经在内存中。顺序读取性能对于跟上查询是非常重要的。

碎片:碎片将导致更多的磁盘头部移动与旋转媒体，增加几毫秒的物理磁盘IO。这通常只是针对单轴或低端本地存储阵列的大规模顺序扫描，而不是SSD或企业级SAN。可以通过重新组织或重建聚集索引来消除碎片。一定要指定MAXDOP 1进行重建，以获得最大的好处。

Server流的结果与客户端应用程序可以使用的速度一样快，但客户端可能受到网络带宽和延迟的限制。似乎您正在返回许多GB的数据，这将需要相当长的时间。使用不同的数据类型，可以大大减少带宽需求。例如，假设GUID命名的列实际上包含GUID，使用unique标识符而不是nvarchar将在netowrk和磁盘上每一行节省约80个字节。同样，如果实际上不需要Unicode字符将数据大小减半，则使用varchar代替nvarchar。

客户端处理时间:应用程序代码处理2000万行的时间将受到CPU和代码效率(特别是内存管理)的限制。由于内存不足，似乎要么将所有行加载到内存中，要么出现泄漏。即使没有彻底的内存错误，高内存使用率也会导致分页和大幅度降低吞吐量。重要的是，如果应用程序代码不能像返回数据那样快速地处理行，那么数据库和网络性能就没有意义了。