SQL Server 2000 查询视图，从1480万条数据中查出12万条数据用时3秒，算慢的吗？

经过昨天版主以及各位高手的指导
我把索引调整到Index Seek的了
但我不知道现在是否是最佳的方案
请问我这样的速度算慢的吗？

现在的执行计划

12 个解决方案

#1

昨天有位高手提到“如果数据量不大的话要走Index Seek”
我这边的实际情况是从4亿条数据中频繁的查询出100万条以内的数据
用现在的方案会不会适得其反？ 因为我不知道100万的数据量算大还是算小

#2

最后这个最好能改成HASH JOIN

12万数据输出本身就需要时间，3秒差不多了

#3

100万挺多的，但是能在3秒内查出来，我觉得已经很优秀了。是否走seek，那是相对而言，没有绝对的“大数据量”

#4

写错了，1000万

#5

引用 1 楼 Steinway 的回复:

昨天有位高手提到“如果数据量不大的话要走Index Seek”
我这边的实际情况是从4亿条数据中频繁的查询出100万条以内的数据
用现在的方案会不会适得其反？ 因为我不知道100万的数据量算大还是算小

你这个需求本身就有点问题，频繁读取100W有多频繁，如果是秒级的话没几个数据库能搞的定，能再细一点么

#6

总的来说如果是大数据量（恩你这个绝对算是大数据量）的查询里如果出现scan基本就是找死

#7

到了一定数据量，hash join的确比较高效。不过速度可以接受的话，就不要过多干预sqlserver的决定，保证统计信息的实时更新和索引列的顺序有效更重要

#8

引用 4 楼 DBA_Huangzj 的回复:

写错了，1000万

啊，版版来啦，今天早晨我这边有5亿条数据，用昨天的方案测试了还是卡死。
随后我把autoID的索引放在最后了，就是现在的这个结果。

顺便问下你今天休息吗？

#9

4亿的话我建议要升级sqlserver了，如果可以，升到2008、2012，然后利用合理的分区、filter index/filter statistics等技术进一步缩小搜索范围，在返回那么大量的数据情况下，要求不要太高

#10

休息，我国庆上了2天，今天不用加班，不同数据量方案不能直接照搬。比如100条数据的表，建不建索引都不大，但是100万，不建就问题大了

#11

谢谢两位，我下午再测试一下，那会儿数据量就多些了。

#12

最好贴近真实环境测试，以前见过有人讨论3000万数据查询，他用几百条数据来测，说某种方式很高效，放到真实环境一样死翘翘。你这种级别的数据，scan已经暗示着有潜在问题，需要去找原因，不过不一定总是代表有问题，SELECT 12*1./1480=0.008108 筛选度还可以，所以建议针对scan做文章，昨天你那个查询就两个表，如果效率不高，可以用hint，把hash和merge join测一遍