Question

我正在基于sql查询生成页面。

这是查询：

CREATEPROCEDURE sp_searchUsersByFirstLetter 
    @searchQuery nvarchar(1)
AS
BEGIN
    SET NOCOUNT ON;

    SELECT UserName
    FROM Users Join aspnet_Users asp on Users.UserId = asp.UserId
    WHERE (LoweredUserName like @searchQuery + '%')

我可以为字母表中的每个字母调用此过程，并获取以该字母开头的所有用户。然后，我将这些用户放在我的一个页面上的列表中。

我的问题是：将用户列表缓存到我的网络服务器，而不是每次都查询数据库会更好吗？像这样：

HttpRuntime.Cache.Insert("users", listOfUsersReturnedFromQuery, null, DateTime.Now.AddHours(1), System.Web.Caching.Cache.NoSlidingExpiration);

如果用户列表是一个小时过时，它对我来说没问题。每次查询数据库会更有效吗？

Answer 1

最好在查询满足以下约束的情况下使用缓存：

数据不是时间关键，即确保缓存命中不会导致您的代码错过最近的数据更新。
数据未按顺序排列，即A，B，C，D，E被缓存，F被另一个用户插入，您的用户插入G并点击缓存，导致ABCDEG而不是ABCDEFG。
数据变化不大。
查询数据并经常重复使用。

大小并不是真正的因素，除非它真的会对你的RAM征税。

我发现要缓存的最佳表之一是设置表，其中数据几乎是静态的，几乎每个页面请求都会被查询，并且不必立即进行更改。

您要做的最好的事情是测试哪些查询执行得最多，然后选择那些对数据库服务器征税最高的查询。除此之外，缓存任何你能负担得起的东西。您还应该看一下调整最大缓存对象的年龄。如果您每秒执行100次查询，只需将其缓存1秒钟即可将该速率降低99％，这可以消除大多数实际情况下的更新延迟问题。

Answer 2

如果您的服务器很少，内存兑现不太好，因为它会在每个服务器和每个服务器的每个w3p进程中记忆。

维护一致的数据也很困难。

我建议选择：

基本输出缓存（假设您正在使用MVC，这是零努力和良好的支持）
使用较小的预先计算的表格进行Db缓存，其中您具有从输入字符串到10种可能结果的映射

Answer 3

这取决于。您是否在数据库服务器上遇到瓶颈（我希望答案是否定的）？如果您在数据库中使用了26次，那么与通常情况相比，这是无关紧要的。如果数十万次访问数据库，您应该考虑在数据集或其他一些离线模型中缓存数据。

所以我会说，没有。你到数据库的往返旅行应该没问题。

但是没有替代测试。那肯定会告诉你。

Answer 4

考虑到每个数据库调用在网络和数据库负载方面总是很昂贵，我宁愿避免这样的额外操作和缓存项目，即使它们每小时请求几次。

我看到的只有一个相反的情况 - 当内存消耗方面的用户数量是一吨兆字节时。

Answer 5

缓存数据和恢复速度最快，但也取决于数据大小...如果数据量大于导致性能问题。

所以这几乎取决于你的要求。

我希望您建议使用分页或通过加载一半放入缓存的用户来使用混合模式，而不是在需要时加载其他数据....

从sql数据库缓存结果，还是每次查询？

5 个答案: