我有一个方法，它在for循环中调用存储过程300次，每次存储过程返回1200条记录。我怎么能改善这个？我不能消除300个电话但是还有其他我可以尝试的电话。我正在使用通过ASP.NET实现的REST服务并使用IBATIS进行数据库连接
答案 0 :(得分：3)
我无法消除300个电话
消除300个电话。
即使您只能添加另一个调用原始存储过程300次的存储过程，聚合结果，您也应该看到了巨大的性能提升。
如果你能编写一个复制原始功能的新存储过程，但结构更适合你的特定用例，那就更好了，而不是一次调用它。
在您的代码和数据库之间进行300次往返非常简单需要时间，即使代码和数据库位于同一系统上也是如此。
一旦解决了这个可怕的问题，如果需要的话，还有其他你可以寻求优化的东西。
答案 1 :(得分：1)
测量
测量服务器端代码中花费的时间。测量存储过程中花费的时间量。衡量在客户端部分花费的时间。做一些数学计算，你粗略估计网络时间和其他开销。
返回1200条记录，我将期望网络带宽成为主要问题之一;您可以调查一个不同的序列化引擎（具有相同的输出类型）是否有帮助，或者是否增加压缩（gzip / deflate）支持是否有益（意味着：减少的带宽比增加的CPU所需的更重要）。
如果要调用REST服务300次，延迟可能很重要;也许你可以稍微并行化，或者减少大量的通话，而不是大量的小电话。
您可以批量处理SQL代码，因此您只需要几次访问数据库（在每个数据库中重复调用SP） - 这是完全可能的;只需使用EXEC等（仍然使用参数化）。
您可以查看如何从ADO.NET获取数据到REST层。你提到了IBATIS，但你有没有检查过它是快还是慢？比如，＆＃34; dapper＆＃34; ？
最后，可以调查SP性能本身;索引或只是重构SP的SQL可能会有所帮助。
答案 2 :(得分：1)
好吧，如果你必须返回360,000条记录，你必须返回360,000条记录。但你真的需要返回360,000条记录吗？从那里开始，一路向下。
答案 3 :(得分：0)
在不了解太多细节的情况下，架构似乎存在缺陷。一方面，使用单个S.P.执行来检索360,000条记录所花费的6秒锁定表是不合理的，但是可以返回通过多个S.P.执行检索的可能不一致的360,000条记录集。它让我想知道你究竟想要实现什么，以及是否有更好的方法来设计客户端和服务器之间的集成。
例如，如果客户端正在检索自上次请求以来创建的一组记录，那么maybe a paged ATOM feed将更合适。
你正在做什么，360,000条记录是在服务器和客户端之间移动的大量数据，我们应该关注数据传输的体系结构和目的，以确保当前的方法是合适的。 / p>