我有一个应用程序可以执行复杂查询，以查询“星型模式”中组织的数据量。黄金所有者不断添加新的“轴”来执行搜索，结果随着时间的推移性能变差。目前，使用存储过程执行SQL服务器上的所有工作的搜索操作的执行大约需要2秒，这不符合金主人希望使代码具有交互性（<0.1秒响应）时间）。查看SQL Server查询分析器，搜索是在100,000个记录的9个表扫描上进行IO绑定，然后进行残酷连接。由于我需要执行的查询的性质和SQL的限制，这无法改进。
绝望之下，我重写了查询处理器，以便在应用程序启动时将100,000条记录吸入缓存中，然后对缓存的内存执行复杂查询。从数据库加载所有记录大约需要12秒。我重写的查询处理器减轻了这种昂贵的初始负载。它现在只需要对记录进行一次扫描，并给出0.02秒的响应时间。
这个好消息被黄金拥有者的发现所污染，即每隔一小时左右就会有12秒的填充缓存。我目前正在将数据存储在ASP.NET应用程序状态中，如Application["FactTable"]。在ASP.NET应用程序空闲超过十几分钟后，似乎正在重置应用程序状态。
如果我将100,000条记录移动到ASP.NET应用程序缓存中，我是否会经常进行这些驱逐，或者我可以依赖内存中的数据来进行更长时间的快速检索？如果ASP.NET缓存也是应用程序重置的牺牲品，我应该使用哪种其他机制？我想到了一个托管我的数据库缓存实例的独立应用程序域，但除非我的其他选项被关闭，否则我不想沿着那条路走下去。
答案 0 :(得分：1)
我意识到你有大量的数据和处理，你必须尝试一些方法来加快这种情况，但使用由IIS管理的应用程序状态将是不稳定的......
您是否考虑过在另一个进程中运行计算等，即创建一个Windows服务，定期运行查询以组织数据并将“平面”数据保存到数据库缓存中。当用户请求数据时，他们只会得到最后一个数据库缓存结果......然后通过将这些结果保存在Application状态中进一步加快速度，如果它被破坏就可以刷新自己？