我有一个包含约800万条记录的MS SQL表。在“ID”列上有一个主键（带有仅0.8％碎片化的聚集索引）。当我运行看似任何引用ID列的查询时，这些查询都需要很长时间（并且最终会使我的应用程序崩溃）。这包括简单的查询，例如“SELECT * FROM table WHERE ID=2020”。相比之下，不引用ID的查询（例如“SELECT TOP 100 * from table”）则没有问题。
您有什么想法？
您有什么想法？
当引用主键时，SQL查询非常缓慢
4
- alpheus
3
“very long” 是什么意思？1秒钟？20秒钟？ - Dean Harding
我不明白为什么 - bigint，PK = Clustered Index与更新的统计信息应该是最好的。没有其他锁定ID = 2020吗？尝试SELECT * FROM table (NOLOCK) WHERE ID=2020。如果所有其他方法都失败了，请尝试删除聚集索引（和所有NC索引）并重新创建。 - StuartLC
为什么应用程序因长时间运行的查询而崩溃？ - pascal
5个回答
4
- gbn
1
@Spence：如果它们被禁用或从未创建，这将无法工作。 - gbn
2
如果查询需要10分钟(!?!)，那么你肯定出了严重的问题。即使是对800万条记录进行表扫描，也应该只需要一两秒钟的时间。我建议检查事件日志以寻找即将出现的硬件故障的迹象，或者尝试将数据库移动到另一台服务器上，以查看是否存在其他硬件故障。
- Dean Harding
1
如果列中存在未经过类型定义的XML blob，该怎么办？ - Spence
1
我猜测查询正在执行表扫描（或者至少是在一个非常大的或统计过时的索引上进行索引扫描）。生成一个估计的执行计划（在SSMS中按Control-L）或让SQL Server返回它实际使用的执行计划，因为有时会不同（按Control-M启用它，然后正常运行查询 - 它将在结果旁边创建一个新选项卡）。
一旦你有了执行计划，搜索表扫描或索引扫描，这很可能是你的缓慢源头。 "估计的执行计划"甚至可能建议一个索引来帮助查询更快地返回 - 新版本的SQL Server / SSMS包括此功能。
虽然我怀疑你不会发现任何有趣的东西 - 你的查询只是一个单一的步骤 - 这里是一个关于阅读执行计划的快速介绍：http://sqlserverpedia.com/wiki/Examining_Query_Execution_Plans。
一旦你有了执行计划，搜索表扫描或索引扫描，这很可能是你的缓慢源头。 "估计的执行计划"甚至可能建议一个索引来帮助查询更快地返回 - 新版本的SQL Server / SSMS包括此功能。
虽然我怀疑你不会发现任何有趣的东西 - 你的查询只是一个单一的步骤 - 这里是一个关于阅读执行计划的快速介绍：http://sqlserverpedia.com/wiki/Examining_Query_Execution_Plans。
- SqlRyan
1
执行计划是一个好主意。它可能涉及索引问题或数据页问题。Alpheus，你能为你的查询添加执行计划吗？ - Burcin
0
ID 是否是 GUID？SQL Server 在 GUID 列上的哈希生成存在问题，这使得它们在索引中表现不佳。
使用 Sql Server Management Studio 获取您的确切查询并抓取“估计执行计划”。如果您的查询触发了表扫描（本不应该），那么这就可以解释时间问题。也许计划可以向您展示其他正在发生的事情。
我假设您已经重建了索引（根据您的 0.8% 碎片化评论）。
- Spence
1
我会尝试。ID 是一个大整型。 - alpheus
0
我猜如果您正在使用默认的读取级别，并且您具有长时间运行的更新操作，您也可能会遇到死锁？这肯定也会引起此问题。
- Spence
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接