27,579
社区成员
发帖
与我相关
我的任务
分享SQL Server 2000 查询视图，从1480万条数据中查出12万条数据用时3秒，算慢的吗？
经过昨天版主以及各位高手的指导
我把索引调整到Index Seek的了
但我不知道现在是否是最佳的方案
请问我这样的速度算慢的吗？
现在的执行计划
我把索引调整到Index Seek的了
但我不知道现在是否是最佳的方案
请问我这样的速度算慢的吗？
现在的执行计划
...全文
请发表友善的回复…
发表回复
發糞塗牆 2013-10-12
- 打赏
- 举报
最好贴近真实环境测试，以前见过有人讨论3000万数据查询，他用几百条数据来测，说某种方式很高效，放到真实环境一样死翘翘。你这种级别的数据，scan已经暗示着有潜在问题，需要去找原因，不过不一定总是代表有问题，SELECT 12*1./1480=0.008108 筛选度还可以，所以建议针对scan做文章，昨天你那个查询就两个表，如果效率不高，可以用hint，把hash和merge join测一遍
热情的菜鸟 2013-10-12
- 打赏
- 举报
谢谢两位，我下午再测试一下，那会儿数据量就多些了。
發糞塗牆 2013-10-12
- 打赏
- 举报
休息，我国庆上了2天，今天不用加班，不同数据量方案不能直接照搬。比如100条数据的表，建不建索引都不大，但是100万，不建就问题大了
發糞塗牆 2013-10-12
- 打赏
- 举报
4亿的话我建议要升级sqlserver了，如果可以，升到2008、2012，然后利用合理的分区、filter index/filter statistics等技术进一步缩小搜索范围，在返回那么大量的数据情况下，要求不要太高
热情的菜鸟 2013-10-12
- 打赏
- 举报
啊，版版来啦，今天早晨我这边有5亿条数据，用昨天的方案测试了还是卡死。
随后我把autoID的索引放在最后了，就是现在的这个结果。
顺便问下你今天休息吗？
發糞塗牆 2013-10-12
- 打赏
- 举报
到了一定数据量，hash join的确比较高效。不过速度可以接受的话，就不要过多干预sqlserver的决定，保证统计信息的实时更新和索引列的顺序有效更重要
guguda2008 2013-10-12
- 打赏
- 举报
总的来说如果是大数据量（恩你这个绝对算是大数据量）的查询里如果出现scan基本就是找死
guguda2008 2013-10-12
- 打赏
- 举报
你这个需求本身就有点问题，频繁读取100W有多频繁，如果是秒级的话没几个数据库能搞的定，能再细一点么
發糞塗牆 2013-10-12
- 打赏
- 举报
写错了，1000万
發糞塗牆 2013-10-12
- 打赏
- 举报
100万挺多的，但是能在3秒内查出来，我觉得已经很优秀了。是否走seek，那是相对而言，没有绝对的“大数据量”
guguda2008 2013-10-12
- 打赏
- 举报
最后这个最好能改成HASH JOIN
12万数据输出本身就需要时间，3秒差不多了
热情的菜鸟 2013-10-12
- 打赏
- 举报
昨天有位高手提到“如果数据量不大的话要走Index Seek”
我这边的实际情况是从4亿条数据中频繁的查询出100万条以内的数据
用现在的方案会不会适得其反？ 因为我不知道100万的数据量算大还是算小
