2015-08-29 44 views
1

我的表基本上是一个访问日志,记录每一页命中。我想要展示的是每年每周的点击次数,每年比较一次(所以我有2013年,2014年,2015年,2013年第2周,2014年等第1周)。我目前仅通过查询所有记录完成这一点,让PHP执行繁重的工作如下:按一年中的星期分组的计数记录

$result=$db->query("select `time` from accessTracking where `uID` is not null and `time`>1357030861 order by `time`"); 
foreach($result as $r){ 
    $y=date("Y",$r['time']); 
    $w=ltrim(date("W",$r['time']),'0'); 
    $accessArray[$w][$y]++; 
} 

虽然它的工作原理,它需要一个坚实的7秒加载它显示在图表上的页面,我想,PHP不仅有更好的方式,MySQL更是如此(这是我正在寻找的,但我会采取任何可以缩短页面加载时间并使整个事情更有效的方法。)

所以,就这样,我想出最好的是:

select weekofyear(`time`) as week, count(*) as count from `accessTracking` where `uID` is not null group by week 

这看起来像它会工作,因为它返回53行,从1-52的“星期”列和“计数”列与他们的随机值范围从2到1100.问题是,数字应该是更高的方式因为我拥有的最高一周大约有27,000次点击,并且此查询中返回的第一条记录是一个空“周”值,“count”值约为398,000。这告诉我,对于大多数记录来说,它不计算weekofyear()值。

我的猜测是,我最终会将其作为每年的单独查询来运行,因为它可能太多以至于不能返回年份,周数和计数,所有这些都按照我想要的方式分组。但谁知道!

+0

按年份添加额外的分组不应该“太多”,并且我相信您正在以正确的方式进行操作。尽管我对'weekofyear()'函数不太了解。 – shawnt00

+0

Fred,表格没有被编入索引,但我不确定它在这里有多大的帮助,我们并没有真正地搜索或整理信息。每个记录都必须进行分析,然后进行排序。分页确实不是一种选择,因为最终结果集(用于显示数据的页面上)只是每年每周的记录数,而不是记录本身。因此,如果您想要显示最近三年的结果,则只能显示156条记录。那里没什么大不了的。 – Patrick

+0

我删除了关于那个Patrick的评论;在你发表你的评论之前,我想到了很多并被删除了。请参阅下面给出的答案。但是,索引会帮助*一点*。 Gordon在SQL方面比我高得多。 –

回答

2

您的查询不具可比性。具体地,第一个具有此条件:

`time` > 1357030861 

这表明time是UNIX时间。我建议你试试:

select weekofyear(from_unixtime(`time`)) as week, count(*) as count 
from `accessTracking` 
where `uID` is not null and `time` > 1357030861 
group by week; 
+0

就是这样。查询工作并在不到半秒内完成。它并没有通过“weekofyear()”看起来正确的价值类型。是的,'time'是一个unix时间戳。看起来我甚至可以在没有太多额外时间的情况下实施这一年。谢谢戈登! – Patrick

0

首先,它不是使用关键字或功能的列名是个好主意,因为它会导致混乱和危险的错误(和记住所有的`字符)。我认为这会做你想做的事情,但随着一年的结果增加。

select weekofyear(from_unixtime(`time`)) as wk, 
     year(from_unixtime(`time`)) as yr, 
     count(*) as ct 
from `accessTracking` 
where `uID` is not null 
group by wk, yr 

对于您所看到的奇怪结果进行故障诊断,您应该查询特定记录并查看它们与聚合的匹配程度。例如:

select `time` as access_time 
from `accessTracking` 
where `uID` is not null and 
     weekofyear(from_unixtime(`time`)) = 1 and 
     year(from_unixtime(`time`)) = 2015 

将该查询的行计数与聚合查询中获得的行数进行比较。他们应该匹配,如果他们不能,你可以更好地看到差异在哪里。当然,我会建议选择一个行数较少的一周来进行故障排除,或者那些显示您感觉错误的结果的行。

+0

我同意关键字问题。不知道我的哈希标记在那个查询中出现的位置,但我很早就遇到了麻烦。感谢提醒,并且您使用from_unixtime()函数与Gordon处于同一轨道。完善。 – Patrick