MySQL性能 - 表的数量。行数

Question

我有两条路线，

1）为每个用户创建子表并存储他的个人内容

2）创建几个表并存储其中所有用户的数据。

例如

。

1）100,000个表，每个表有1000行

2）50个表，每个表有2,000,000行

我想知道哪条路线是最好和最有效的。

背景：像Facebook，数百万用户，他们的帖子，照片，标签。所有这些信息都在一些巨型表中供所有用户使用，或者每个用户都拥有自己的子表。

Answer 1

这是MySQL中这两种方法的优点和缺点。

<强> 1。许多小桌子。

缺点：

• 使用更多并发表意味着需要更多文件描述符（检查this）
• 拥有100.000个表的数据库很乱。

<强>赞成：

• 小表意味着小索引。小索引可以完全加载到内存中，这意味着您的查询运行得更快。
• 此外，由于索引较小，像插入一样的数据操作会运行得更快。

<强> 2。几张大桌子

<强>缺点：

• 一张巨大的表意味着非常大的指数。如果您的索引无法完全加载到内存中，则大多数查询都会非常慢。

<强>赞成：

• 数据库（以及你的代码）清晰易懂。
• 如果您的表变得如此之大，您可以使用分区。 （查看this）。

根据我的经验，我有一个包含两百万行的表（我已经使用了七千万行表），如果你能够在内存中加载所有活动索引，那么MySQL下的性能问题就不是了。

如果您有许多并发用户，我建议您评估其他类似Elastic Search的技术，这些技术似乎更适合这种情况。

Answer 2

为每个用户创建一个表是更糟糕的设计。这是你在db design class中教授的第一件事。

Answer 3

Table是数据库的强大逻辑组件，因此它被RDBMS用于许多维护任务。例如。习惯上设置表文件空间，限制，配额，日志空间，事务空间，索引树空间和许多其他东西。如果每个表都有自己的文件来放入数据，那么在加入表格时你将获得很大的往返时间。

当您创建许多表时，您将在维护方面遇到很大的开销。此外，你将否认关系来源的本质。假设您正在向数据库添加记录 - 每次都创建一个新表？你的代码会有点困难。

但话说回来，你可以亲自试试。

Answer 4

您应该利用MySQL indexes的功能，该功能基本上将提供类似于每个用户只有一张表的功能。

创建一个在 user_id 上建立索引的名为 user_data 的表（大图）将转换在上具有 where 子句的查询user_id 就像这样：

SELECT picture FROM user_data WHERE user_id = INT

进入：

• 在索引中查找 user_data 中的行，其中 user_id = INT
• 然后，在这批行中，将 picture
的值加载给我

这样做，MySQL不会搜索 user_data 的所有行，而是搜索索引中的相关行。