1

已经有 1200 万个帖子，人们似乎在用东西聊天。我不知道拥有一堆小表是否比让数据库扫描具有如此多条目的数据库中的最后 10 条消息更有效。我知道我必须进行基准测试，但只是询问是否有人有任何观察或轶事，如果他们曾经有过类似的情况。

编辑添加架构：

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;
4

3 回答 3

4

使用变量表名不是一个好主意。如果您已对将转换为单独表的列进行索引，则数据库使用索引将比创建单独表做得更好。这就是数据库的设计目的。

于 2012-07-01T03:13:05.123 回答
2

我假设这里的“线程”是指帖子池中的线程。

在这里获得长期可扩展性的方法是开发一种架构，在该架构中您可以拥有多个数据库实例，并避免需要跨所有实例执行查询。

在同一个数据库上创建多个表在可伸缩性方面并没有真正的帮助。（事实上​​，它甚至可能会降低吞吐量......由于增加了数据库缓存的负载。）但听起来在您的应用程序中，您可以在不同数据库中划分为消息“池”，前提是您可以安排一个回复消息与它回复的消息进入同一个池。

出现的问题是某些事情将涉及查询所有数据库实例中的数据。在这种情况下，它可能会列出所有用户的消息，或者进行关键字搜索。因此，您确实必须查看整个图片以找出如何最好地实现分区。您需要分析所有查询，并考虑它们的相对频率。归根结底，解决方案可能涉及对模式进行非规范化，以便可以对数据库进行分区。

于 2012-07-01T03:15:49.303 回答
2

动态表在关系模式中通常是一个非常糟糕的主意。键/值存储进行了不同的权衡，因此有些存储在动态表等方面表现更好，但以弱数据完整性/一致性保证等为代价。您似乎没有定义任何外键引用并且您正在使用 MyISAM，因此数据完整性/可靠性可能不是优先事项；要理解的重要一点是，不同的设计有不同的擅长的东西，所以对于一个数据库来说好的设计对于另一个数据库来说可能是坏的设计。

当我专注于 Pg 时，我无能为力，这是一个 MySQL 问题。取消标记。

（请注意，至少在 PostgreSQL 中，关系集上的许多操作都是 O(n)，因此大量的关系可能是非常有害的。）

于 2012-07-01T11:21:15.410 回答