captureTime 加一个索引看看先。

加索引，分表

电话簿都有索引啊。

#1 楼 @xds2000 #2 楼 @rasefon #3 楼 @Rei 其他类似的表也有这个字段，加了 BTREE 索引。。。。 但这个表当初比较少用，所以没加。想不到。。。。如果要加的话，900W 数据估计也要两三个小时了。

还有其他方案吗？

#5 楼 @hooooopo 老师那边对架构之类的东西根本就不是很在乎，比较看重算法应用层面的东西。每次我们推理都去 select，数据量大就受不了了，性能直线下降。。。。。除了加索引，我们也不知道怎么去处理。。。所以就这样一直拖着拖着。。。

#6 楼 @zhangsm 索引对查询是十分管用的，对 count 有用么？估计只能用 hadoop 之类的 map-reduce 吧。

#7 楼 @chenge 可能下学期考虑搭集群了。

大概是统计最近一周每天产生多少记录吧 好多解法，最简单的就是在 time 上加索引 然后把 curdate 函数去掉 order 也去掉

#4 楼 @zhangsm 主题"于 2 小时前发布"

#9 楼 @hooooopo 嗯嗯。

#10 楼 @Rei ？？

900w 数据一点都不多，加个索引吧。 常规方法（比如索引）能解决的问题，就不要用一些偏门方案，因为偏门方案有其他问题，你到时候又要开一个帖子来解决新方案的问题。

#13 楼 @kgen 嗯嗯。

为 captrueTime 加上索引，保准立竿见影

如果还想更快的话，一般还要建立一个按日的统计表，然后每天凌晨跑一次数据，查询直接查统计表，引入的新问题是当天统计数据在统计表没有体现，如果需要要额外想办法。

按天分表。然后做一些 helper 方法。比如根据天来确定表明什么的。

#16 楼 @vincent 我现在就是这样做的。用一个定时线程跑统计，每隔小时统计一次，缓存起来。每次从缓存拿数据就行了，效果很理想。

#17 楼 @xu_xiang_yang 现在暂时不考虑分表的做法，因为没做过。先了解一下。。。。

900W 真心不多，我们有张表 2 亿多数据，存储用户行为。有很多索引都是后期建的，查询的时候也要按 ID 砍，查初始日期的 id 最小值，和结束日期的 id 最大值。

#19 楼 @zhangsm 造成速度慢的主要原因是 group by date_format(captureTime,'%Y-%m-%d') #20 楼 @hanluner 嗯，以前也是这么搞得，效率很高。

增加一个字段，存储 date_format(captureTime,'%Y-%m-%d') 的内容，然后 group by 这个新字段。

1.其实 900 万还不是特别多 2.尽早建索引 select 去查肯定可以应付 3.未雨绸缪，早点筹划分表

#4 楼 @zhangsm 用不了那麼久啊~~我們幾千萬的數據也才幾十分鐘

#21 楼 @xiaogui 贊同，因為索引上是不能有轉化那類的函數..........還有例如 in、like 等，這樣的查詢條件索引并不起作用，所以樓主的 group by 過程還是比較耗時的