引用主键时 SQL 查询异常缓慢答案

【问题标题】：SQL queries exceedingly slow when referencing primary key引用主键时 SQL 查询异常缓慢
【发布时间】：2011-04-06 14:37:33
【问题描述】：

我有一个包含大约 800 万条记录的 MS SQL 表。 “ID”列上有一个主键（带有只有 0.8% 碎片的聚集索引）。当我运行看似引用 ID 列的任何查询时，查询需要很长时间（实际上最终会导致我的应用程序崩溃）。这包括简单的查询，例如“SELECT * FROM table WHERE ID=2020”。相比之下，不引用 ID 的查询（例如“SELECT TOP 100 * from table”）就可以了。

有什么想法吗？

【问题讨论】：

“很长”是什么意思？ 1秒？ 20 秒？
我不明白为什么 - bigint, PK = 具有更新统计信息的聚集索引应该尽可能好。没有别的锁定 ID = 2020？尝试 SELECT * FROM table (NOLOCK) WHERE ID=2020。如果一切都失败了，请尝试删除聚集索引（和所有 NC 索引）并重新创建。
为什么应用程序会因为长时间运行的查询而崩溃？...

标签： sql sql-server database performance database-design

【解决方案1】：

ID 是 GUID 吗？ SQL Server 在 GUID 列上生成哈希时存在问题，这使得它们在索引中表现不佳。

获取您的确切查询并从 Sql Server Management Studio 中获取“估计的执行计划”。如果您的查询正在触发表扫描（它不应该是），那么这将解释时间。也许该计划可能会向您展示正在发生的其他事情。

我假设您已经重建了索引（基于您的 0.8% 碎片评论）。

【讨论】：

我会试试的。 ID 是一个大整数。

【解决方案2】：

我怀疑该查询正在执行表扫描（或者，至少是对非常大的索引或统计数据过期的索引进行索引扫描）。生成估计的执行计划（SSMS 中的 Control-L）或让 SQL Server 返回它实际使用的执行计划，因为它有时不同（Control-M 启用它，然后正常运行您的查询 - 它会在您的旁边创建一个新选项卡结果）。

一旦你有了执行计划，搜索表扫描或索引扫描，这很可能是你运行缓慢的原因。 “估计的执行计划”甚至可以推荐和索引以帮助查询更快地返回 - 较新版本的 SQL Server/SSMS 包含此功能。

虽然我怀疑你不会发现任何有趣的东西 - 你的查询只是一个步骤 - 这里有一个关于阅读执行计划的快速介绍：http://sqlserverpedia.com/wiki/Examining_Query_Execution_Plans

【讨论】：

执行计划是个好主意。它可能涉及索引问题或数据页问题。 Alpheus，你能为你的查询制定执行计划吗？

【解决方案3】：

如果您已经检查过碎片，我会检查统计信息

它们是被禁用还是没有更新？

他们快速检查的方法是使用STATS_DATE

【讨论】：

@Spence：如果它们被禁用或从未创建，这将不起作用。

【解决方案4】：

如果查询花费了 10 分钟（！？！），那么您就有问题严重了。即使是 800 万条记录的表扫描也只需要一两秒。我会检查事件日志中是否有即将发生硬件故障的迹象，或者尝试将数据库移动到其他服务器以查看是否存在其他硬件故障。

【讨论】：

如果列中有无类型的 XML blob 怎么办？

【解决方案5】：

我猜如果您使用默认读取级别并且您有长时间运行的更新，您可能也会遇到死锁？这也肯定会导致这种情况。

【讨论】：