【问题标题】:MySQL: Which is smaller, storing 2 sets of similar data in 1 table vs 2 tables (+indexes)?MySQL:在 1 个表和 2 个表(+索引)中存储 2 组相似数据,哪个更小?
【发布时间】:2014-03-31 21:22:43
【问题描述】:

我被要求为某个站点优化(按大小)统计系统,我注意到他们将 2 组统计数据存储在一个表中。这些集合是搜索列表上的产品展示和产品页面上的访问。每行都有一个产品 ID、统计日期、统计计数和统计标志列。标志列指示它是搜索列表显示还是页面访问统计。统计数据每天存储,产品 id、统计日期(实际上结合产品 id 和统计类型)和统计计数都有索引。

我想知道将这两组存储为单独的表或将它们保存为一个单独的表是否更好(在大小方面)。我认为会产生影响的部分是标志列(假设它是一个 1 字节的 TINYINT)和索引。我对索引占用的空间在 2 表场景中如何变化特别感兴趣。有问题的表已经有几百万条记录。

当我有更多时间时,我可能会做一些测试,但我想知道是否有人已经挑战过类似的问题。

【问题讨论】:

  • 我建议按照你的建议做一些测试。
  • 你能显示当前表的创建表语句吗?

标签: mysql


【解决方案1】:

通常,如果两种观察结果一致,最好将它们放在一个表中。我所说的“符合”是指它们的基本数据是相同的。

看来你的观察确实符合。

这是为什么?

首先,您可以轻松地添加更多一致的观察结果。例如,您可以通过向标志列添加新值来将销售额添加到搜索列表和产品页面视图。

其次,您可以很容易地报告各种观察结果的组合。如果您将这些东西分开到不同的表中,当您想将它们重新组合在一起时,您将执行 UNION 或 JOIN。

第三,当索引正确完成时,访问时间基本相同。

第四,磁盘空间使用差异小。无论哪种情况,您都需要索引。

第五,磁盘空间成本的差异是微不足道的。您有几百万行,或者换句话说,有十几个千兆字节。最高质量的 Amazon Web Services 存储成本约为每年每 GB 1.00 美元。这比你重构这些东西所花费的办公室热量要少。随它去。

【讨论】:

    【解决方案2】:

    我终于有时间进行测试了。这只是一个包含 12k 和 48k 记录的小规模测试。

    存储这两种数据的表具有以下结构:

    CREATE TABLE IF NOT EXISTS `stat_test` (
    `id_off` int(11) NOT NULL,
    `stat_date` date NOT NULL,
    `stat_count` int(11) NOT NULL,
    `stat_type` tinyint(11) NOT NULL,
    PRIMARY KEY (`id_off`,`stat_date`,`stat_type`),
    KEY `id_off` (`id_off`),
    KEY `stat_count` (`stat_count`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin2;
    

    另外两个表的结构如下:

    CREATE TABLE IF NOT EXISTS `stat_test_other` (
    `id_off` int(11) NOT NULL,
    `stat_date` date NOT NULL,
    `stat_count` int(11) NOT NULL,
    PRIMARY KEY (`id_off`,`stat_date`),
    KEY `id_off` (`id_off`),
    KEY `stat_count` (`stat_count`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin2;
    

    在 12k 条记录的情况下,2 个单独的表实际上比存储所有内容的表略大,但在 48k 条记录的情况下,两个表更小,而且值显着。

    最后我没有把数据分成两张表来解决我最初的空间问题。通过删除冗余的id_off 索引并调整数据类型(在大多数情况下unsigned smallint 足以存储我需要的所有值),我设法大大减小了数据库的大小。请注意,最初 stat_type 也是 int 类型,对于此列 unsigned tinyint 就足够了。总而言之,这将数据库的大小从 1.5GB 减少到了 600MB(我的数据库限制仅为 2GB)。此解决方案的另一个优点是我不必修改一行代码即可使一切正常运行(由于该站点是由其他人编写的,因此我不必花费数小时试图理解源代码) .

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-03-05
      • 2012-12-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多