在 mysql 表上的 EPOCH 时间上使用 GROUP BY 子句答案

【问题标题】：Using GROUP BY clause on EPOCH time on mysql table在 mysql 表上的 EPOCH 时间上使用 GROUP BY 子句
【发布时间】：2016-06-14 07:30:53
【问题描述】：

我在 mysql 表 TEST 中有几百万条记录。

TEST 表的一列 (TRIAL_TIME) 将 EPOCH 时间存储为 BIGINT。触发一个 sql 查询，该查询使用 GROUP BY 子句在 TRIAL_TIME 对数据进行分组。

查询是这样的。

SELECT SUM(A1), COUNT(B1) 
from TEST 
WHERE <some clause> 
GROUP BY TRIAL_TIME DIV 300000 
ORDER BY <some column>;

上述查询中的 300000 表示我希望将数据分组的时间。例如，如果我想按 1 分钟对数据进行分组，我会使用 60000。然后查询变为

SELECT SUM(A1), COUNT(B1) 
from TEST 
WHERE <some clause> 
GROUP BY TRIAL_TIME DIV 600000 
ORDER BY <some column>;

问题是

这会是一个有效的查询吗？
如果没有，有什么更好的方法？
开放以使用 ALTER 表来适应更好的解决方案。

可能的解决方案之一是添加新列并解析 EPOCH 时间以提取 DATE、TIME 等字段并使用适当的值更新新创建的列，以便 GROUP BY 变得更容易。

想知道这是否是一个明智的解决方案？

注意 - 记录使用 mysql 5.1 和 Infobright 引擎。当前查询大约需要 3 分钟来执行（因为 GROUP BY CLAUSE）。性能目标是将其控制在 30 秒以内。

【问题讨论】：

当 TIMESTAMP 专为此目的而设计时，为什么将纪元时间存储在 BIGINT 中
这已经是一个遗留问题。无法控制它。但是你是说存储为日期时间会有帮助吗？
不只是考虑是否值得冒险提供答案。如果犯了这么简单的错误，我会不会在泥潭里跌跌撞撞？
你有 TRIAL_TIME 的索引吗？
不。它是排序的。

标签： mysql performance group-by epoch infobright

【解决方案1】：

WHERE ... -- With a good index, this _might_ be less of a problem; otherwise it needs scan
GROUP BY FLOOR(ts/300000) -- adding a column will not help
ORDER BY something_else -- this will force [another] sort

您要扫描多少行？如果它是一个很大的数字，那么在没有某种形式的汇总表的情况下期望高速是不合理的。

您提到了 Infobright，但您没有提到在数据存储中“首选”哪个键。 Infobright 将跳过与WHERE 子句不匹配的 64K 行块；你在利用它吗？如果不是，则需要从所有块中解压缩所有相关列。

Summary tables -- 但是，它并没有考虑到 Infobright。

【讨论】：