在SQL Azure上执行相同的简单选择语句或存储过程会花费很长时间或超时

Question

我有两个带有Standard S2的SQL Server Azure实例：50个DTU。 当我在两个实例上运行简单的select语句时，其中一个比其他实例花费更多的时间或超时。 较慢的实例在较慢的实例中表中的记录更多。

这两个实例具有相同的表架构。 在较慢的实例中存在的表中的记录数，LogEvidence表具有1324928，而LogItem表具有649391。在较快的实例中存在的表中的记录数，LogEvidence表具有89504，而LogItem表具有89496。

下面是简单的选择语句

select count(*) from logitem 

上面的简单选择语句在较快的实例上为0，在较慢的实例上为138。 而且，如果我执行任何存储过程，则速度较慢的实例将花费更多时间或超时。

两个实例所花费的时间应该几乎相同。

Answer 1

这些简单的查询在表上执行大型扫描，并涉及读取所有行。 如果表具有聚集索引，则不必执行SELECT COUNT（*）即可知道表具有的记录数。 以下查询应该可以更快地进行：

SELECT OBJECT_NAME(ps.object_id) , i.name , row_count 
FROM sys.dm_db_partition_stats AS ps INNER JOIN sys.indexes AS i 
ON ps.index_id = i.index_id AND ps.object_id = i.object_id 
WHERE i.name like '%logitem%'

如果该表没有ID，请在该表上添加一个autoid，并使其成为聚集索引。

您还可以尝试向查询中添加如下所示的无用WHERE子句，这样可能会获得更好的性能。

SELECT count(*) 
FROM logitem 
WHERE id > 0

其中id是autoid列。

Answer 2

我有一些天蓝色的经验，根据您的描述，我认为您可以执行以下操作之一：

1. 由于仅使用计数，因此索引不起作用。 虽然我理解其他答案说使用where id>0 ，但是azure应该计数100万行而没有30秒超时。 但是对于其他查询，则需要索引，否则Azure将失败。

2. 检查您的服务器是否不在维护中，这是很小的机会，但是确实发生在我们身上，我们在s4上，有时我们的服务器速度变慢，但是在10到30分钟后，它可以正常工作。 也许实际的硬件进入某个过程会使其速度变慢。

3. 这是执行速度缓慢的最重要原因，尤其是在服务器上发生大量写入和删除操作的情况下。 检查数据库大小。 Azure数据库碎片化得太快了，我们必须每10天对其数据碎片进行一次优化，如果bacpac大小为100MB，而Azure中的数据库大小显示为5-6 GB，那么肯定会需要优化，因为会生成很多碎片。 MSDN提供了一些查询来重新创建索引并消除碎片，我不记得它们的URL，但是简单的Google搜索会带来这些。 它应该加快速度。

4. Azure具有自动生成索引，检查两个表是否共享相同索引的功能，也许您的较快版本具有Azure自己创建的某些索引。

Answer 3

您应该退后一步并思考一下您的假设：1.“性能应该大致相同” –在一种情况下，您有更多的数据。 在极限条件下，您应该期望第二个的性能可能会比原始的性能稍慢。

现在，让我们来研究“为什么”它会更慢，以及如何调查每种情况：步骤1：查看每种情况的查询计划，看看有什么。 可能会有类似以下内容的内容：StreamAgg <-聚集索引扫描（如果您有其他b树索引，则可以扫描其中一个，并且可能会更快，因为索引不会那么宽，因此索引会更少扫描页面）

步骤2：您可以查看每个查询的实际执行时间和资源使用情况，以了解它们为何不同。 一种方法是先运行“设置统计信息打开时间”，然后运行“设置统计信息打开时间”，然后运行查询。 当您从那里运行查询时，它将把额外的信息转储到SSMS中。 （您可以在此处阅读有关此内容： https : //docs.microsoft.com/zh-cn/sql/t-sql/statements/set-statistics-io-transact-sql?view=sql-server-2017 ）

如果查看每个输出的输出，则可能会发现性能不同的原因。 一种可能的解释是，S2中的内存量是有限的，并且您正处于所有页面都适合内存的边界，而不是两个示例。 在那种情况下，执行count（*）查询将需要循环遍历所有页面，并且比可能已经全部存在于内存中的较小情况下做更多的IO。

步骤3：您还可以潜在地检查查询存储，以了解为什么一种情况很快而另一种情况不是很快。 有关如何使用它的概述，请访问： https : //docs.microsoft.com/zh-cn/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql- server-2017注意：它在SQL Azure中是默认设置，因此您可以在运行查询时查看时间窗口，以洞悉数据库中当时的情况。

最后，如果需要更快的查询，您可能会考虑使查询更快的方法。 *在表上创建一个狭窄的b树索引可能会有助于该查询（count（*）不返回任何列，只需要一些未过滤索引中的行数即可）。 *您可以使用Columnstore（出于内存原因，它需要S3或更高版本）。 这种面向列的索引已针对此类查询进行了优化，并且随着将来表的大小增加，它会更快。

希望对您有所帮助