我有一个 MVC 应用程序需要运行几个tilion 计算。其中，我只对大约 800 万个结果感兴趣。我必须做这项工作，因为我需要看到一个整体的高分和低分。我将保存这些数据，并将其存储在一个包含 16 个浮点数的表中。我在这个表上也有一些索引用于查找。到目前为止，我只处理了 5% 的数据。
当用户将数据输入我的网站时，我必须根据他们的数据进行计算。我必须确定最好和最差的结果。这只是大约 400 万次计算。现在，在我的本地 PC 上计算大约需要一秒钟或更短的时间。或者它是一个简单的查询，它将始终从我存储的数据中返回 2 条记录。最好的和最坏的。现在，获取结果的查询与计算结果的速度相同或更快，但我还没有全部 800 万条记录。我担心数据库会变慢。
我在想我会使用数据库查找，如果性能成为问题，请切换到运行时计算。
问题：我是否应该省去麻烦并进行运行时计算？我不确定哪个选项更具可扩展性。我不希望这个网站有庞大的用户群。该网站需要活泼。
您的问题有点含糊，无法提供明确的答案，但我的猜测是使用 db 计算总数将比您在网站上编写代码更有效率。Sql Server 将尝试优化查询以使用尽可能多的服务器资源以提高效率。除非您专门为此编写代码，否则您的代码不会这样做。
在制定优化策略之前，我会先加载数据并进行测试。在加载远程接近您将要处理的数据之前，您不知道系统的真正瓶颈在哪里。
如果我理解执行计算的问题更具可扩展性，那么它是否在单个数据集上。当您将数据添加到表中时，即使使用索引查找也会变慢。此外，索引会增加表大小并增加插入记录所需的时间。
如果我对您的理解正确，这是一个关于缓存的问题-您应该即时计算还是在缓存中查找结果？
在大多数 Web 架构中，您的 SQL 数据库是一个出色的缓存，直到它变成一个糟糕的缓存。众所周知，扩展 (SQL) 数据库非常棘手 - 引入集群、分片等本身就成为一种产品。
我的 - 非常笼统的 - 建议是使用关系数据库来管理事务数据，并使用缓存技术进行缓存。如今，一台体面的服务器上的 RAM 应该可以容纳 800 万条记录——而且您可以添加 Web 服务器，而且比扩展您的数据库要便宜得多。