对于 163,020 行的表，SELECT [所有列] 需要 1:02答案

【问题标题】：SELECT [all columns] takes 1:02 for table with 163,020 rows对于 163,020 行的表，SELECT [所有列] 需要 1:02
【发布时间】：2019-02-18 22:02:16
【问题描述】：

这是一个 Azure SQL 数据库。这是一张小桌子，真的。我没有做 SELECT * FROM。我正在命名表中的所有列。

该表具有带有聚集索引的 PK。它还有一个包含两列的非聚集索引。

最初，SELECT 语句需要 39 秒才能运行。但是在我对两个索引都进行了 REORGANIZE 之后，现在需要 1:02。所以，我让事情变得更糟。（幸好这是一个 DEV 表。）

我怎样才能至少恢复到我开始时的 39 秒？而且，我还应该寻找什么来解释缓慢？

如果有帮助，这里是执行计划。

我还启动了 SQL Profiler 并运行了跟踪，但它返回了太多数据，老实说，我不知道我在寻找什么结果。

这是SELECT @@Version的结果

Microsoft SQL Azure (RTM) - 12.0.2000.8
2019 年 1 月 3 日 00:14:33
版权所有 (C) 2018 Microsoft Corporation

【问题讨论】：

【解决方案1】：

也许重建索引？创建一个覆盖索引 - 一个包含所有被选择的列的索引 - 将允许查询立即运行。除此之外，是否有任何列包含非常大的斑点？我也会研究磁盘 IO 性能。这似乎异常缓慢。

【讨论】：

谢谢！它是一个 Azure SQL 数据库，所以我不确定如何查看磁盘 IO 性能。至于覆盖索引，我不确定这是什么意思，但我会去谷歌它！
覆盖索引是一个非聚集索引，包含查询所需的所有字段。
您应该注意的一件事是，索引过多也会导致问题，因此请确保对为特定表创建的索引数量保持平衡。
他必须使用覆盖索引，否则解释计划将通过 rid 再次与表连接，并且图像中的所有内容都从索引中恢复
我可能会这样解决问题。首先，我只选择 PK 列。如果性能好，我会继续添加列，直到性能下降，然后我会看到它告诉我的内容。如果性能不好，我会检查是否是网络问题，所以我会执行“select * into #sometemptable from ”，如果速度很快，怀疑是网络传输问题。如果 select into 仍然很慢，我将不得不开始变得更加认真。

【解决方案2】：

根据 BoCoKeith 的评论，我认为网络延迟似乎是问题所在。它参差不齐且不一致。但是，此查询将始终在 00:00 秒内运行：

SELECT * INTO #sometemptable FROM MyTable

虽然这需要从 00:20 到 01:40 的任何时间

SELECT * FROM MyTable

【讨论】：