Mysql亿级数据如何设计分表？

Question

现在有一张阅读奖励log表大概亿级数据(存储大小50G)
表结构，id,num(阅读奖励次数)，uid(用户id)，acid(文章id),ac_url(文章路径),atime,channel(渠道)
现在这张表有三个常用查询语句
1.使用uid来查询这个用户的累积阅读次数sum(num)
2.使用atime查询时间范围内累积阅读奖励次数sum(num)
3.使用uid+atime查询累积阅读奖励次数sum(num)
现在以上查询已经很慢了，想请问分表或分区如何操作？
如果按照每天分表2和3的时间范围查询岂不是每次都要联合查询？
如果按照用户id后四位分表那只提升了1查询的效率吧？时间查询还是联合查询

还有旧数据是如何最快速度写入到分表里的等等，不胜感激！

真心求教如何解决问题。感谢?！

Answer 1

1. 使用MySQL中间件分表 (可以按月分表) (不是比较好的解决方案)
2. 建议使用分布式数据库 例如TiDB 或者阿里云的商用分布式数据库

Answer 2

• 根据uid哈希后（或如你所说后四位）分表；支持1，3的查询

  • 优势：并发：根据uid分表，将并发负载平摊至各表；如果按时间分表，那并发问题无法解决
• 2的查询由上表，每日定时汇总，单独计入一个表（或分表，按月等）

如上面同学所说，TIDB也行。

Answer 3

为啥不是直接增加两个表记录sum(num)? 一个是根据uid一个根据atime, 按道理这种日志式的数据写(只有create没有update)的次数会远远小于查的次数, 更何况是每个查询都sum, 相当于是每个查询都要迭代完整个result.

如果强行按你现有的方案的话只能二选一咯, 这个按历史调用次数及成本分析下就ok了

Answer 4

分表的话，我之前是按照 uid % 50 取模（和hash一个意思）。比如：table_0/table_1.../table_49
这样的缺点就是按时间查询费劲一点。
具体按时间分表，还是按uid分表，主要看那个查询要多一点。

另外，数据量都上亿了，为什么还考虑mysql呢？可以换ElasticSearch之类的吧。
如果经常查询汇总数据，也可以定时自动先把数据汇总到一个表里，便于查询。

Answer 5

统计类的功能，对实时性和准确性要求不是特别高，建议新建汇总表，晚上定时做增量数据的汇总更新，通过预计算解决性能的问题。