优化方式有很多啦，也不用分表。

比如 summary 表，定期按需把聚合数据导入到一个新表，在新表里做统计分析。使用 group by + select into 或简单的 ETL 倒一次很快的。

PS. 一般用来分析的表，时间也不这么存，只存到天，甚至存 date_id。

#17 楼 @chrisloong 登录啊 想看看验证码。。。在哪里

服务器出现了一点小问题！

看看查询语句咯

思路是尽量别让服务器出错，尽早在 dev 和 staging 环境把问题暴露出来...

如果还是出错了，建议 exception notify、remote pry

十万个为什么

#38 楼 @yue ok.

#34 楼 @yue 没看过，那个 repo 里都是很老的电子书。Enterprise Rails 我觉得不错，讲了一些平时接触不多的思路，有在线版：http://dan.chak.org/enterprise-rails/

看不懂

#29 楼 @ruby_sky updated.

https://github.com/mangochiman/RUBY-ON-RAILS-BOOKS-

是 Prime Stack 的首选啊！

有这时间都把 Ruby 升级完了

seed dump

#5 楼 @lmorenbit 没用缓存插件就是 rails 自身的 bug 了 建议换 4.1 试试。因为 4.2 type cast 改动比较大……

#3 楼 @lmorenbit 用缓存没

rails 4.2?

#7 楼 @huacnlee 是的。unicorn 文档里对这个强调了好多次。。。还有一个常见的陷阱，把外部调用写在 after_save/update 之类 callback 里，导致事物长时间不关闭。

• 所有外部调用一定要设 timeout.
• 外部调用一定要 after_commit.

#6 楼 @qige023 那是你不理解 jwt

jwt

顶。。

无度量，不优化。 谢谢

#3 楼 @est you got it.

用 Rails，你就是 Rails 开发者。用别的，你是 Ruby 开发者^_^

Awesome！

墨刀，还以为是一种货币

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

#14 楼 @moyerock ⊙_⊙

1. unicorn 有单独的 error log，不知道 puma 有没有，可以看看那个日志
2. 压力测试不反应真实情况，newrelic 按上试一下，免费版的就可以
3. 检查一下外部请求和服务，包括 redis memcache 等