0

我一直在考虑在下表结构中保留历史记录：

`id` bigint unsigned not null auto_increment,
`userid` bigint unsigned not null,
`date` date not null,
`points_earned` int unsigned not null,
primary key (`id`),
key `userid` (`userid`),
key `date` (`date`)

这将允许我用它的 Reputation Graph 做类似 SO 的事情（我可以​​在其中看到自从我加入该站点以来我的声望增益）。

不过，问题出在这里：我只是进行了一个简单的计算：

SELECT SUN(DATEDIFF(`lastclick`,`registered`)) FROM `users`

结果几乎没有差别 25,000,000 个工日。如果我打算每天为每个用户保留一行，那将是一张 [expletive] 大表，我期待进一步的增长。即使我排除了用户不上网的日子，这仍然是巨大的。

任何人都可以就维护如此大量的数据提供任何建议吗？将在此表上运行的唯一查询是：

SELECT * FROM `history` WHERE `userid`=?
SELECT SUM(`points_earned`) FROM `history` WHERE `userid`=? AND `date`>?
INSERT INTO `history` VALUES (null,?,?,?)

例如，ARCHIVE发动机在这里有用吗？或者我不需要因为索引而担心？

4

1 回答 1

1

假设它的mysql：

  1. 对于历史表，您应该考虑分区，您可以为您设置最佳分区规则并查看您有哪些查询，有两种选择：
    a。按日期分区（例如 1 个分区 = 1 个月）
    b. 按用户分区（假设您有 300 个分区和 1 个分区 = 100000 个用户）
    如果您要使用分区修剪，这将帮助您分配（这里）

  2. 您可以为 user,date 使用复合索引（它将用于前 2 个查询）

  3. 避免INSERT语句，当您有大量数据时使用LOAD DATA（这将不起作用，因为表已分区）

最重要的是……处理海量数据的最佳引擎是 MyISAM

于 2013-04-12T15:32:28.723 回答