如果線程得到3000個帖子，每個線程可能會更好地創建一個新表？

已經有1200萬個帖子，人們似乎在使用聊天功能。我不知道擁有一堆小表比讓數據庫掃描數據庫中最後10條包含這麼多條目的消息更有效。我知道我不得不進行基準測試，只是詢問是否有任何人有任何意見或軼事，如果他們曾經有類似的情況。如果線程得到3000個帖子，每個線程可能會更好地創建一個新表？

編輯附加模式：

create table reply(
id int(11) unsigned not null auto_increment, 
thread_id int(10) unsigned not null default 0, 
ownerId int(9) unsigned not null default 0, 
ownerName varchar(20), 
profileId int(9) unsigned, 
profileName varchar(50), 
creationDate dateTime, 
ip int unsigned, 
pic varchar(255) default '', 
reply text, 
index(thread_id), 
primary key(id)) TYPE=MyISAM;

來源

2012-07-01 ForeverConfused

如果沒有必要不要進行非規範化，和唐不要盲目索引：修補東西可能會使它們變得更糟。你是否真的有性能問題，或者你只是謹慎？模式如何？你記錄緩慢的查詢？ –

我確實通過註釋中的線程ID進行索引。我只是想知道這是否是一個有效的選擇。最近我一直在研究leveldb和其他經常使用多個表的關鍵價值商店，所以我一直在質疑這個設置。編輯爲計劃 – ForeverConfused

是否有涉及任何開源論壇或博客引擎？ –

我假設這裏的「線程」代表線程在帖子池中。

您將在這裏獲得長期可擴展性的方式是開發一種架構，您可以在其中擁有多個數據庫實例，並避免需要在所有實例之間執行查詢。

在同一個數據庫上創建多個表格對於可伸縮性無關緊要。（事實上，由於增加了數據庫緩存的負載，它甚至可能會降低吞吐量。）但是，聽起來就像在應用程序中，您可以將其劃分爲不同數據庫中的「緩衝池」，前提是您可以安排對消息的回覆將與其回覆的消息進入同一個池。

出現的問題是，某些事情將涉及在所有數據庫實例中跨數據查詢。在這種情況下，它可能會列出用戶的所有消息，或者進行關鍵字搜索。因此，您必須查看整個圖片以瞭解如何實現分區。您需要分析所有查詢，並考慮到它們的相對頻率。並且在一天結束時，解決方案可能涉及非規範化架構，以便可以對數據庫進行分區。

來源

2012-07-01 03:15:49

這不是使用變量表名是個好主意。如果您已將索引轉換爲單獨表格的列，那麼使用索引的數據庫將比創建單獨的表格更好。這就是數據庫的設計目的。

來源

2012-07-01 03:13:05

動態表在關係模式中通常是一個非常糟糕的主意。主要/價值商店做出了不同的折衷，所以有些企業在動態表格等方面做得更好，但其代價是數據完整性/一致性保證不力。您似乎沒有定義任何外鍵引用，並且您正在使用MyISAM，因此數據完整性/可靠性可能不是優先級;要了解的重要一點是不同的設計有不同的優點，所以對於一個數據庫而言，最好的設計可能是另一個數據庫的糟糕設計。

因爲我專注於Pg，所以我無法提供幫助，這是一個MySQL問題。去標記。

（請注意，在PostgreSQL的，至少，在關係集中，很多操作都爲O（n），所以關係的巨大的數字可以說是相當有害的。）

來源

2012-07-01 11:21:15

如果線程得到3000個帖子，每個線程可能會更好地創建一個新表？

回答

相關問題