我有一个典型的情景，我从性能的角度来努力。用户从下拉列表中选择一个值并单击按钮。存储过程将该值作为输入参数，执行并将结果返回到网格。对于其中一个值（'All'），查询运行大约2.5分钟。对于其余值，查询运行时间小于1毫秒。
显然，让用户等待2.5分钟就不会飞。那么，处理这个问题的典型策略是什么？
我自己的一些想法：
感谢任何帮助。
谢谢！
更新
更多信息：
sp返回两个结果集。第一个是按汇总汇总的分组，第二个是第一个结果集，分解（大约80,000行）。
答案 0 :(得分：2)
我先看看你是否有适当的索引。使用查询分析器和数据库调优助手是查看索引可能有用的一种简单且经常有效的方法。
如果在创建适当的索引后仍然存在性能问题，那么您可能会考虑添加表/视图以加快速度。如果您的查询执行了大量连接，您可以考虑创建一个索引视图，该视图允许您对非规范化数据执行选择而不加入连接。由于索引视图是持久的，因此您可以从使用它们中获得巨大收益。
您可以在此处阅读索引视图：
http://msdn.microsoft.com/en-us/library/dd171921%28v=sql.100%29.aspx
并在此处阅读有关数据库调优顾问的信息：
http://msdn.microsoft.com/en-us/library/ms166575.aspx
此外，“全部”会返回多少条记录？我之前看到人们在“全部”场景中被挂起，但如果它返回100万条记录或者某些内容，那么数据无论如何都无法用于某人......
答案 1 :(得分：1)
缓存数据是一件好事，但是......如果SP本质上存在缺陷，那么你可能想要实际修复它而不是试图用缓存来封装它。
你可能也想（因为你在这里没有提到）查看行数＆＃34; All＆＃34;返回与其他选择相比并考虑您的索引。
同样在你的SP中，＆＃34; All＆＃34;导致它运行不同的tsql集合，例如可能是一个案例或者if ...或者它是否运行相同的代码只是使用不同的＆＃34; WHERE＆＃34;？
可能只是＆＃34; ALL＆＃34;只返回很多记录。您可能希望使用ajax实现分页和部分数据集返回...（有点像提前返回前1000条记录，以便可以显示它，并在返回其余数据集时在屏幕上显示悸动）
这些都是选项...如果记录的数量确实不同于ALL和其他...那么它可能与查询/索引/程序流有关。