为什么在SQL Server中对索引列执行top(1)会很慢？
为什么在SQL Server中对索引列执行top(1)会很慢？
提问于 2010-03-16 19:04:18
我对以下几点感到困惑。我有一个大约有1000万行的DB，并且(在其他索引中)1列(campaignid_int)是一个索引。
现在我有700k行，其中campaignid确实是3835
对于所有这些行，connectionid都是相同的。
我只想找出这个connectionid。
use messaging_db;
SELECT TOP (1) connectionid
FROM outgoing_messages WITH (NOLOCK)
WHERE (campaignid_int = 3835)现在这个查询大约需要30秒来执行！
我(凭我的数据库知识)希望它接受任何行，并返回给我那个connectionid。
如果我在一个只有1个条目的活动中测试同样的查询，它会运行得非常快。所以索引起作用了。
我该如何解决这个问题?为什么这个不起作用？
编辑：
estimated execution plan:
select (0%) - top (0%) - clustered index scan (100%)回答 4
Stack Overflow用户
回答已采纳
发布于 2010-03-16 20:52:11
根据统计数据，您应该显式地要求优化器使用您创建的索引，而不是聚集的索引。
SELECT TOP (1) connectionid
FROM outgoing_messages WITH (NOLOCK, index(idx_connectionid))
WHERE (campaignid_int = 3835)我希望它能解决这个问题。
向您致敬，Enrique
Stack Overflow用户
发布于 2012-11-22 17:28:18
我最近遇到了同样的问题，它真的很容易解决(至少在某些情况下是这样)。
如果您在任何或某些已索引的列上添加ORDER BY-clause，应该可以解决这个问题。这至少解决了我的问题。
Stack Overflow用户
发布于 2010-03-16 19:55:04
您没有在查询中指定ORDER BY子句，因此没有指示优化器选择前1的排序顺序。SQL Server不会只接受随机的行，它会按某个值对行进行排序，然后取前1，并且它可能会选择按次优的值进行排序。我建议您添加一个ORDER BY x子句，其中x是该表上的聚集键，可能是最快的。
这可能不会解决您的问题--事实上，我不确定从您给出的统计数据中我是否期望它能解决--但是(a)它不会有什么坏处，(b)您可以排除这是一个促成因素。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/2453765
复制相关文章
相似问题