【问题标题】:Should I split large table into smaller identical ones in this case?在这种情况下,我应该将大表拆分成较小的相同表吗?
【发布时间】:2013-05-08 14:45:48
【问题描述】:

假设您有一个多站点脚本,例如如果同一件事有多个实例(如论坛托管)。如果使用 MySQL,是为每个站点创建一组新的表,还是使用一个带有 site_id 列的大表更好?

一张表当然更容易维护,但性能又有什么关系呢? 另外如果我使用Redis,答案会不会有什么不同?

【问题讨论】:

  • 人们是否需要访问多个站点数据?
  • 提供更多信息。这取决于您将创建什么类型的网站。每小时有多少个请求(平均),依此类推……
  • 最接近的例子是论坛托管。表是完全独立的,一次使用的数据永远不会超过 1 个。

标签: mysql performance optimization


【解决方案1】:

停止试图智取您的 DBMS,您不会赢得这场战斗。您的数据应该在逻辑上分成表格,而不是出于性能原因。

您所描述的实际上是试图重新发明索引的一次失败尝试。

【讨论】:

    【解决方案2】:

    您不会看到拥有多个表的任何性能差异很大,正如 John 所说,索引会做得更好。

    但是您可能会看到性能提升,因为表锁定将特定于该站点的论坛表,而不是锁定所有站点的单个论坛表。但是好的查询和架构是防止这些锁影响性能的更好方法。

    您可以在同一个数据库服务器上拥有多个数据库,每个站点一个数据库。这是有道理的,因为这意味着每个站点都将拥有独立的用户表和论坛表,然后每个站点都有自己的资源池。但是,如果单个用户将使用多个论坛并且现在必须拥有多个用户记录(以及任何其他不特定于论坛帖子的数据),则此重复数据。

    您可以通过在使用它们的应用程序服务器附近(在网络意义上)放置完全不同的数据库服务器来减少延迟。但实际上,现在全国范围内的服务器响应 ping 的时间不到十分之一秒,而且这是针对家庭用户的,对于托管服务提供商处的服务器来说可能要好一些。

    所有这些都是没有意义的,除非您实际看到的使用超出了单个数据库中的单个表可以处理的范围。在您获得一些关于瓶颈所在位置的真实统计数据之前,不要试图解决您甚至不知道它们是否会破裂的问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-10-26
      • 1970-01-01
      • 2011-01-17
      • 2022-07-22
      • 2013-05-16
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多