报告一百万行的最佳方式

Question

我有两个数据库表subscription和transaction，其中一个订阅可以包含许多事务。订阅的状态主要取决于属于它的事务。因此，如果我想计算下一个处理日期，我会查看订阅对象的句点字段，然后分析订阅的事务以确定其状态。一切正常。

我面临的问题是该表包含超过400,000个订阅对象和数百万个事务记录，因此构建订阅的报告摘要（例如，从大约10个可能的状态中的每个状态中有多少个）变得有点棘手。动态计算）

由于计算每个订阅状态的所有逻辑都在c＃代码中，因此我必须使用linq-to-sql加载包含所有子事务对象的订阅对象的完整图。这需要相当长的时间，也许两分钟左右。我正在考虑缓存，但不会给出实时结果。我只是想知道是否有一个可以解决这个问题的策略，或者我的数据库上的索引可能会加速linq到sql查询。或者，如果我从一开始就设计得非常糟糕。

感谢。

Answer 1

  

由于所有逻辑都要计算   每个订阅的状态是   c＃代码，我必须加载一个完整的   所有订阅对象的图形   他们的子交易

也许你不应该在客户端加载所有这些数据并逐行进行所有计算。这就是数据库实际上擅长的。在服务器端进行计算，最好还是将计算存储在表中，然后在报告中查找。如果您有400k订阅和+ M交易，那么您设计的基石是数据库，而不是客户端。您需要在数据模型中投入时间和设计，客户端之后。

Answer 2

每次访问订阅对象时，是否必须重做所有计算？在某些情况下，可以将最后计算的结果存储在对象中（或在新表中）并从那里开始计算。您可能需要使用结果保存计算中包含的最后一个事务的ID。 如果在您的情况下这是可行的，您将只能将未处理的事务加载到内存中。

Answer 3

创建适当的索引（在您的问题中没有足够的信息来了解它们是什么）。如果您拥有良好的索引，那么一百万行并不是一个运行联接查询的集合。

您是否可以创建一个包含计算所需状态的逻辑的视图？这可能会减少I / O，因为不必将大量数据返回给客户端。

Answer 4

数据库问题的标准答案取决于。您需要分析问题以确定瓶颈所在。主要成本是从磁盘读取数百万行吗？或者它是通过网络发送数百万行？或者它是否在内存中存储了数百万行？

因为每个问题都有完全不同的解决方案。例如，如果发现您的问题是由于在实内存和虚拟内存之间交换数据，那么构建其他索引将无济于事（除非有一个索引可用于预过滤结果以减少数量行返回）。