关于索引

关于索引。求助

有个表，里面建了非聚集索引，可是select的时候，为什么是索引scan，而不是索引seek呢？求助。。。。

语句为：select * from sPurchase_201209 where Pur_Item_Code = 2369409

求助~~~
[最优解释]
索引是在这个字段吗？ 如果在  可能是索引失效  建议重建索引
[其他解释]
 清空缓存
dbcc dropcleanbuffers
 你强制使用索引对比下IO

select * from sPurchase_201209  with(index=IndexNAme) 
 where Pur_Item_Code = 2369409

可能是查询优化器给你又花了，scan的代价并不一定比seek高
[其他解释]
可能是查询优化器给你优化了，scan的代价并不一定比seek高

写错字了
[其他解释]
更新一下统计信息
[其他解释]
问题1、可能统计信息过时。
问题2、你的数据分布太零散，导致需要scan才能找到所有数据
[其他解释]

引用:

索引是在这个字段吗？ 如果在  可能是索引失效  建议重建索引

是在那个段的。。我先去重建试试。。
[其他解释]

引用:

引用:索引是在这个字段吗？ 如果在  可能是索引失效  建议重建索引
是在那个段的。。我先去重建试试。。

还有就是可能你那个字段的数据重复率太高了
[其他解释]

引用:

索引是在这个字段吗？ 如果在  可能是索引失效  建议重建索引

Alter index all on sPurchase_201209 Rebuild  with  (fillfactor=90, sort_in_tempdb = ON)
已使用上述语句rebuild索引，但是执行计划里还是索引scan。。为毛。。。
[其他解释]
晕，搞那么多非聚集索引干嘛？你这样容易影响查询优化器的分析，不要每个列都单独搞一个索引
[其他解释]

引用:

引用:
引用:索引是在这个字段吗？ 如果在  可能是索引失效  建议重建索引
是在那个段的。。我先去重建试试。。

还有就是可能你那个字段的数据重复率太高了

一共有200W条数据，那个字段的有12W条唯一记录。。。。
[其他解释]

引用:

晕，搞那么多非聚集索引干嘛？你这样容易影响查询优化器的分析，不要每个列都单独搞一个索引

一共有40多列，只是在几个常用的字段上建的索引~~
[其他解释]
你的索引命名也有问题。不过这个先不管，试试把常用的列合在一个非聚集索引里面，然后把现有的除聚集索引外的列禁用再试试
[其他解释]

引用:

更新一下统计信息

我在别的索引列上做条件写查询，用的都是索引seek。。这个列真怪
[其他解释]

引用:

清空缓存
dbcc dropcleanbuffers
 你强制使用索引对比下IO

select * from sPurchase_201209  with(index=IndexNAme) 
 where Pur_Item_Code = 2369409

可能是查询优化器给你又花了，scan的代价并不一定比seek高

用with index确实是索引seek。。不用with index就是索引scan，真蛋疼。。看来要加上with index了。。感谢。。结贴算了
[其他解释]
强制使用with很容易出问题。先要找出为什么scan才是根本
------其他解决方案--------------------

引用:

引用:清空缓存
dbcc dropcleanbuffers
 你强制使用索引对比下IO

select * from sPurchase_201209  with(index=IndexNAme) 
 where Pur_Item_Code = 2369409

可能是查询优化器给你又花了，scan的代价并不一定比seek高
……

你急啥，这里是查询优化器给你优化后的结果，查询优化器认为“scan比seek代价小”就选择了scan
你强制使用索引，结果页不一定最优啊
原因可能是索引碎片，
或者是数据分布导致，你的查询条件的数据在整个表中分布的太多

查看更多 下一篇