引用主键时SQL查询速度极慢

我有一个包含大约800万条记录的MS SQL表。在“ID”列上有一个主键（聚簇索引只有0.8％的分段）。当我运行貌似任何引用ID列的查询时，查询花费很长时间（实际上最终导致应用程序崩溃）。这包括简单的查询，如“SELECT * FROM table WHERE ID = 2020”。相比之下，不引用ID的查询（例如“SELECT TOP 100 * from table”）就没有问题。引用主键时SQL查询速度极慢

任何想法？

来源

2010-09-01 alpheus

“非常长”是什么意思？ 1秒？ 20秒？ – 2010-09-01 04:09:02

超过10分钟。 – alpheus 2010-09-01 04:13:25

我不明白为什么 - 更新统计数据的bigint，PK = Clustered Index应该和它一样好。没有别的锁定ID = 2020？尝试SELECT * FROM表（NOLOCK）WHERE ID = 2020。如果一切都失败了，请尝试删除聚集索引（和所有NC指数）并重新创建。 – StuartLC 2010-09-01 04:16:02

如果查询花费10分钟（！？！）你已经得到的东西严重错误。即使是800万条记录的表扫描也只需要一两秒。我会检查事件日志中是否存在即将发生的硬件故障，或者尝试将数据库移至其他服务器以查看是否存在其他硬件故障。

来源

2010-09-01 04:19:49

如果列中存在无类型的XML blob会怎么样？ – Spence 2010-09-01 05:26:54

ID是一个GUID的机会吗？ SQL Server在GUID列上产生了散列问题，这使得它们在索引中表现不佳。

准确查询并从Sql Server Management Studio中获取“预计执行计划”。如果您查询触发表扫描（它不应该），那么这将解释时间。也许这个计划可能会告诉你还有什么事情发生。

我假设你已经重建了索引（根据你的0.8％碎片评论）。

来源

2010-09-01 04:02:33 Spence

我会试一试。 ID是一个bigint。执行计划 – alpheus 2010-09-01 04:04:55

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

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

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

来源

2010-09-01 04:16:22 SqlRyan

是个好主意。它可能引用索引问题或数据页面问题。 Alpheus，你可以把你的查询执行计划吗？ – 2010-09-01 06:47:03

我检查的统计数据，如果你已经检查碎片

他们被禁用或没有更新？

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

来源

2010-09-01 04:18:07 gbn

exec sp_updatestats – Spence 2010-09-01 04:18:57

@Spence：如果他们被禁用或从未创建，这将无法正常工作。 – gbn 2010-09-01 05:38:34

我想如果你使用的是默认的阅读水平，并且你有一个很长的运行更新，你可能会遇到死锁？这肯定也会造成这种情况。

来源

2010-09-01 06:17:45 Spence

引用主键时SQL查询速度极慢

回答

相关问题