来自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 + '%')

我可以调用这个过程字母表中的每个字母，并得到所有以该字母开头的用户。然后，我将这些用户列入我的一个网页的列表中。

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

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

对于我来说，如果用户列表是一个过时的小时，对我来说还可以。每次查询数据库会更高效吗？

来源

2011-10-17 Oliver

使用缓存是最好的保留您的查询满足以下限制情况：

的数据不是时间关键，即确保高速缓存命中将不会导致你的代码错过了最近的数据更新打破你的应用程序。
数据没有排序，即A，B，C，D，E被缓存，F被另一个用户插入，用户插入G并且命中缓存，导致ABCDEG而不是ABCDEFG。
数据变化不大。
数据经常被查询和重复使用。

大小不是一个真正的因素，除非它真的会给你的RAM加税。

我发现缓存的最佳表格之一是一个设置表，其中数据实际上是静态的，在几乎每个页面请求中都会查询，并且更改不必立即生效。

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

来源

2011-10-17 12:42:01 Polynomial

这真的取决于。你的数据库服务器瓶颈吗（我希望答案是否定的）？如果你打了26次数据库，那么与通常发生的事情相比，这并不算什么。如果数据库访问数十万次，则应考虑在数据集或其他离线模型中缓存数据。

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

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

来源

2011-10-17 12:31:39

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

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

来源

2011-10-17 12:31:49 sll

那么缓存数据和取回速度最快，但它也取决于数据大小......如果数据量过大，会导致性能问题。

所以它几乎取决于您的要求。

我想你化妆建议使用分页或通过加载用户投放缓存和负载比当需要其他数据的一半使用的混合模式....

来源

2011-10-17 12:32:19

如果您的服务器数量少，内存兑现不太好，因为它会在每台服务器和每台服务器的每个w3p进程中使用memroy。

这将是很难保持一致的数据。

我会建议可供选择：

基本输出缓存（假设你使用MVC，这是零的努力和良好的imporevement）
数据库高速缓存输入字符串到10个可能的结果

来源

2011-10-17 12:47:35 st78

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

回答

相关问题