处理可变时间查询的策略？答案

【问题标题】：Strategy for handling variable time queries?处理可变时间查询的策略？
【发布时间】：2011-04-04 17:02:11
【问题描述】：

从性能的角度来看，我遇到了一个典型的场景。用户从下拉列表中选择一个值并单击一个按钮。存储过程将该值作为输入参数，执行并将结果返回到网格。对于其中一个值 ('All')，查询运行大约 2.5 分钟。对于其余值，查询运行时间少于 1 毫秒。

显然，让用户等待 2.5 分钟是行不通的。那么，有哪些典型的策略来处理这个问题呢？

我自己的一些想法：

感谢任何帮助。

谢谢！

更新

更多信息：

sp 返回两个结果集。第一个是按汇总汇总的分组，第二个是第一个结果集，已分解（大约 80,000 行）。

【问题讨论】：

【解决方案1】：

我会先看看您是否有适当的索引。使用查询分析器和数据库调优助手是查看哪些索引可能有帮助的一种简单且通常有效的方法。

如果在创建适当的索引后仍然存在性能问题，您可以考虑添加表/视图以加快处理速度。如果您的查询执行大量连接，您可能会考虑创建一个索引视图，该视图允许您在非规范化数据上执行不连接的选择。由于索引视图是持久的，因此您可以从它们的使用中看到巨大的收益。

您可以在此处阅读索引视图：

并在此处阅读有关数据库调优顾问的信息：

另外，“All”返回多少条记录？我以前见过人们对“全部”场景感到困惑，但如果它返回 100 万条记录或其他东西，那么数据无论如何对一个人都是不可用的......

【讨论】：

【解决方案2】：

缓存数据是一件好事，但是.... 如果 SP 本身存在缺陷，那么您可能希望实际修复它，而不是尝试用缓存包扎它。

您可能还想（因为您没有在此处提及）查看与其他选择相比“全部”返回的行数，并考虑您的索引。

同样在您的 SP 中，“All”是否会导致它运行不同的 tsql 集，例如在 case 或 if 中......还是它运行相同的代码只是使用不同的“WHERE”？

可能只是“ALL”只返回了很多记录。您可能希望使用 ajax 实现分页和部分数据集返回......（有点像提前返回前 1000 条记录，以便在返回数据集的其余部分时显示并在屏幕上显示一个 throbber）

这些都是选项...如果 ALL 和其他记录的数量确实没有那么大的差异...那么它可能与查询/索引/程序流程有关。

【讨论】：

sp没有缺陷，只是数据很多。
就像我说的，如果它返回那么多数据缓存或异步返回是你最好的选择。对许多人来说，依赖于错误查询的缓存...如果您对自己的 SP 有信心，并且返回那么多行，那么还有其他选择。
第二点：无论参数如何，代码都是相同的（单个代码路径），isnull 包裹在参数周围，当传递“全部”时，它实际上将参数设置为 null。
是否有包含空值的内部连接？因为这会让任何查询都陷入困境。
@Patrick - 不确定我是否关注。所有的连接条件都不会包含空值（构成连接的左侧和右侧的字段都不会有空值）