【发布时间】：2018-04-13 08:47:18
【问题描述】：
我是一家公司的实习生，我和我的实习生同事的任务是创建报告仪表板。我们正在使用 MVC、API 和 SQL Server。
目前，我们正在使用 9 种不同的存储过程为仪表板获取数据。这些存储过程使用聚合函数（即某人进行了多少销售）进行一些计算，并根据日期范围（以及其他一些过滤器，如产品）进行过滤。通常，一个存储的 proc 结果集返回大约 100 到 200 行，根据数据库中大约 70 000 行原始数据计算得出 - 如果日期范围过滤器设置为一个月。所以我们得到了大约 9 个表，每个表有 100-200 行来填充我们的仪表板
我们的问题是用户可能会更改各种过滤器，这目前需要我们再次从数据库中获取所有九个结果集，并且目前有点慢 - 刷新大约需要 15 秒或更长时间
我团队中的一位实习生想要更改代码，以便以原始格式（即数据库中每个存储过程的 70 000 行）从数据库中调用所有数据而不进行过滤，然后应用用户过滤器和 C# 中的计算。当然，这去掉了日期范围过滤器，这意味着将返回数据库中的所有数据，因此每个存储的过程将返回大约 2 520 000 行，而不是 70 000 行，因为数据库大约有 3 年历史......并且当然总行数会每月增加。
我不知道这是否是个好主意...我不知道它是否会提高性能。所以我基本上有两个主要问题：
- c# 是否能够比 SQL 更快、更高效地运行这些计算（一个人的销售额）
- 如果有 9 个表，每个表调用到前端，大约有 250 万行数据（和计数），这不会导致一切都变慢，从而使任何好处都无效
另一个建议是花时间改进存储过程本身，并更改前端以并行而不是按顺序调用这些存储过程，这就是我们现在所做的。
回答： 好吧，所以在阅读了所有回复之后，前进的道路似乎是修复那些存储的过程并提高它们的性能。虽然 c# 可能会更快地进行计算，但它无法弥补移动数据和存储数据所需的资源，并且这些存储的过程不应该像它们一样慢。
我们可以使用包含过滤器的 c# 来实现，但在 SQL 中实现似乎更好。
有没有办法可以选择每个人的输入作为答案？
【问题讨论】：
-
一个经过良好调整的 C# 程序可能比 SQL 引擎更快地执行计算，特别是如果您跨线程分配工作，但问题就变成了将 C# 需要的数据从数据库移动到内存所花费的资源（并在返回途中存储结果（如果需要）。 SQL 引擎还使用他们的 sql 魔法（索引和统计信息）来优化行的选择阶段，这在您的 C# 应用程序中可能不是最好的（如果您想过滤而不只是进行计算）。
-
删除过滤器不是个好主意
-
您首先应该问的问题是为什么查询速度很慢。聚合 70K 行不应花费 15 秒，也不应从仅 2.5M 中选择 70K 行。哪一个是瓶颈？首先，确定从 2.5M 中选择 70K 是您的瓶颈还是聚合。如果选择缓慢，请确保您正确使用可用索引；如果没有，请确保所需的索引在表中可用。如果只是聚合很慢，那么它的表述方式可能有问题。作为后备，获取 70K 行并在 C# 中聚合；但在数据库中过滤。
-
是否可以测试取回所有数据 - 它可能会在应用程序启动时添加完全不可接受的延迟。此外，您是否需要当前信息 - 在这种情况下，您要么需要更多存储过程来获取最新数据，要么再次检索整个 20 多万条记录。
-
没有单一的方法可以回答这个问题，因为这两种方法都有争论。当许多功能仅作为 SQL 和 SQL 函数/过程实现时，我发现很难进行适当的单元测试，但如果你能管理这部分，我肯定会考虑它。但是，您也可以在 C# 中更有效地实现计算，因为 SQL 天生对复杂的数据结构和命令式逻辑很挑剔，在我们的产品中，如果没有为它。所以 +/-
标签： c# sql asp.net-mvc performance stored-procedures