2011-09-01 27 views
2

我有一個私人消息系統爲我的瀏覽器遊戲。當我使用查詢檢查大部分CPU時間時,我發現這個表是使用最多的CPU。我不擅長索引,查詢時間優化。所以我想獲得關於此表的優化提示。你會如何優化這個SQL Server 2008 R2表

好吧,現在我要第一個告訴你的表結構:

結構圖像

enter image description here

好吧,這下面的查詢讀取多少未讀郵件沒有用戶具有與此查詢是大多數CPU使用一個,因爲它讀取每頁負載:

SELECT COUNT([Id]) [Number] 
FROM [MyTable] 
WHERE [ReceiverUserId] = @1 
    AND [ReceiverReaded] = @2 
    AND [ReceiverDeleted] = @3 

那麼什麼樣的索引等可以提高我的表現?

回答

1

可能適用於您的應用程序的不同方法:當用戶沒有明確請求任何內容時,根本不查詢消息表,例如,當他不在你的遊戲的「消息」部分。

嘗試使用整數值列來擴展您的用戶表,指出有多少條消息存在以及已經有多少條消息被讀取。每次修改消息表時,還要修改用戶表中的相應值。

這樣你就不需要在每次刷新時查看整個表格。但請注意,這種方法的低迷是程序員的一些額外的同步工作。如果你正確地封裝了消息表的修改(添加消息,讀取消息,刪除消息),這應該不成問題。

+0

其實這是最好的主意:)我可以做到這一點。它會花費更多的編碼時間,但由於這是最消費CPU的查詢,它值得^^ – MonsterMMORPG

+0

我不明白這是如何提高整體性能的。它可能會增加這個查詢的速度......但這隻會以減慢對消息表的寫入爲代價。 – Chains

+0

查看該圖像:d http://img18.imageshack.us/img18/6430/howincrease.png – MonsterMMORPG

2

您總是希望在您正在搜索的字段上使用索引,因此您可能會通過在[ReceiverUserId],[ReceiverReaded]和[ReceiverDeleted]上添加索引來提高查詢性能。

當然,您索引的列越多,UPDATES和INSERTS越慢。

+0

我是否添加3個不同的索引? – MonsterMMORPG

+0

這一切都取決於您將針對此表執行哪些其他查詢。例如,如果您有另一個只查看ReceiverReaded的查詢,則可以使用3個單獨的索引。 – PaulStock

+0

如果我沒有,只有看起來ReceiverReaded我應該如何使索引? – MonsterMMORPG

2

數據庫優化中一個相當簡單的經驗法則是在WHERE子句或JOIN中索引作爲謂詞一部分出現的任何列。從你的例子這些特殊情況包括:

  • ReceiverUserId
  • ReceiverReaded
  • ReceiverDeleted

也有許多可用的優化工具,將「守」你的數據庫,並告訴你什麼列最佳性能指數。

+0

你可以給一些優化工具名稱謝謝 – MonsterMMORPG

+0

查看前三個鏈接:http://www.google.com/search?rlz=1C1SNNT_enUS377US377&sourceid=chrome&ie=UTF-8&q=sql+server+optimization+tools我喜歡RedGate的SQ Server產品,但還有其他選項。 –

3

爲什麼在這些列上都允許NULL - 無論是否讀取。只是默認爲0.然後在Read/Deleted/ReceivedUser上索引(如果您需要大量ALL READ訪問,它們將被「分區」,或者,如果大多數讀取僅針對單個用戶,則將索引放在ReceivedUser )

你想要做的是看到你的索引被覆蓋。在你的情況下,你可以把一個索引放在ReceiverUserId和INCLUDE列的ReceiverReaded和ReceiverDeleted,它將覆蓋(對於該查詢)。在執行計劃中,你應該看到索引查找,因爲你有一個用戶。

您可以捕獲工作負載,然後通過SQL Server中的索引調整嚮導運行它,它可能會提出很好的建議。當然,你需要解釋它告訴你的是什麼。

+0

感謝您的回答。實際上它們的默認值是0,所以從不爲空。有沒有關於索引調整嚮導的任何好的參考資料? – MonsterMMORPG

+0

@MonsterMMORPG在工具菜單上 - 您只需調整窗口中的特定查詢,或者您可以使用分析器捕獲跟蹤,然後使用數據庫引擎優化顧問爲您提供有關整個工作負載的建議。 –

1
  1. 在您的搜索字段中搜索(根據@ PaulStock的回答)。
  2. 將您的tinyint字段更改爲位字段(默認值爲0)
  3. 您的身體真的需要nvarchar(4000)嗎?這是巨大的!考慮更短的消息(比如nvarchar(300)或更小) - 僅供參考,Twitter僅爲140。)
+0

改變他們的位從來沒有出現我的想法偉大的想法:D我不認爲這樣的消息列確實會影響此查詢性能,因爲我不尋求它。 – MonsterMMORPG

+0

大小很重要...: - )...對於您列出的特定查詢,它可能沒有太大的區別(它仍然會在虛擬表1中),但是您提到調整其他查詢 - 如果其中有任何查詢選擇身體,如果你可以讓場地變小,你應該會看到改善。 – Chains

+0

是的,這是正確的:) – MonsterMMORPG