來自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數據庫的緩存結果，還是每次查詢？

回答

相關問題