因此，我創建了一個包含多個主題的網站，人們在這些主題中發佈內容，人們可以對內容發表評論。人們也可以評論評論，但只有一個深度。所以會有評論和子評論，沒有別的。所有關於子註釋的評論將作爲主評論的子註釋列出。我不喜歡20級深度評論，每個級別都有縮進標記。它毀掉了我的頁面的外觀。在Mysql中處理多個索引時最好的策略是什麼
現在我想到了3桌這裏。一個內容表，其中包含內容編號以及主題編號。包含評論編號，內容編號和主題編號字段的評論表。包含子註釋編號，註釋編號和內容編號以及主題編號的子註釋表。
現在我想在subcomment表分配指標時，我的最佳策略應該是什麼。我是否應該將subcomment id單獨分配給一個索引，還是應該將子註釋ID，註釋ID，內容ID和主題編號分配給所有這四個索引？
我一般會指數任何你可能會運行一個查詢，特別是因爲這評論板，如果你希望任何流量可言，沒有索引它們可以在評論的呈現嚴重減緩。
編輯： 的決定真的取決於你希望如何人的因素作出反應。該網站將加載更多的索引，但更新可能會慢一點。由於多人不可能同時更新信息，但人們一般都想先閱讀，我會依靠更快的時間。
MySQL能使用多列索引爲測試索引中的所有的列的查詢或查詢該測試只是第一列，第一列2中，第一3列，依此類推。如果您在索引定義中以正確順序指定列，則單個組合索引可以加速同一個表上的多種查詢。
很多認爲我們就可以創建基於查詢中使用的列，每列索引。但事實並非如此。但是，實際上，查詢的性質本來應該指向正確的構建方式。這是最初的經驗法則：
例如，想象你在三列上搜索一張桌子
州，縣，郵編。
你有時只能按狀態搜索。你有時候會按州和縣進行搜索。你經常按州，縣，郵編搜索。然後是一個包含州，縣，郵編的索引。將用於所有這三項搜索。
如果您通過zip進行搜索相當多，那麼不會使用上述索引（無論如何由SQL Server使用），因爲zip是該索引的第三部分，查詢優化程序將不會看到該索引有幫助。
然後你可以在這個實例中使用Zip創建一個索引。
我想你要找的答案是它取決於你經常使用的查詢的where子句以及你的group by。
製作過多索引會有什麼傷害嗎？喜歡有什麼權衡？ – user17282
更多索引將加速選擇，但會減慢插入，更新和刪除操作。基本上你只需要決定檢索數據然後更新它是否更重要。考慮用例模型。在這種特殊情況下，我會嚴重依賴更快的選擇;您不希望人們在等待加載時離開您的網站。如果他們評論？他們已經想聽到了。 – nomistic
這裏有一個參考：http://stackoverflow.com/questions/4120160/mysql-too-many-indexes – nomistic