Mysql億級(jí)數(shù)據(jù)如何設(shè)計(jì)分表？

現(xiàn)在有一張閱讀獎(jiǎng)勵(lì)log表大概億級(jí)數(shù)據(jù)(存儲(chǔ)大小50G)
表結(jié)構(gòu)，id,num(閱讀獎(jiǎng)勵(lì)次數(shù))，uid(用戶id)，acid(文章id),ac_url(文章路徑),atime,channel(渠道)
現(xiàn)在這張表有三個(gè)常用查詢語句
1.使用uid來查詢這個(gè)用戶的累積閱讀次數(shù)sum(num)
2.使用atime查詢時(shí)間范圍內(nèi)累積閱讀獎(jiǎng)勵(lì)次數(shù)sum(num)
3.使用uid+atime查詢累積閱讀獎(jiǎng)勵(lì)次數(shù)sum(num)
現(xiàn)在以上查詢已經(jīng)很慢了，想請(qǐng)問分表或分區(qū)如何操作？
如果按照每天分表2和3的時(shí)間范圍查詢豈不是每次都要聯(lián)合查詢？
如果按照用戶id后四位分表那只提升了1查詢的效率吧？時(shí)間查詢還是聯(lián)合查詢

還有舊數(shù)據(jù)是如何最快速度寫入到分表里的等等，不勝感激！

真心求教如何解決問題。感謝?！

回答

編輯回答

凹凸曼

使用MySQL中間件分表 (可以按月分表) (不是比較好的解決方案)
建議使用分布式數(shù)據(jù)庫例如TiDB 或者阿里云的商用分布式數(shù)據(jù)庫

2017年1月20日 08:08

編輯回答

殘淚

為啥不是直接增加兩個(gè)表記錄sum(num)? 一個(gè)是根據(jù)uid一個(gè)根據(jù)atime, 按道理這種日志式的數(shù)據(jù)寫(只有create沒有update)的次數(shù)會(huì)遠(yuǎn)遠(yuǎn)小于查的次數(shù), 更何況是每個(gè)查詢都sum, 相當(dāng)于是每個(gè)查詢都要迭代完整個(gè)result.

如果強(qiáng)行按你現(xiàn)有的方案的話只能二選一咯, 這個(gè)按歷史調(diào)用次數(shù)及成本分析下就ok了

2018年2月17日 11:24

編輯回答

來守候

分表的話，我之前是按照 uid % 50 取模（和hash一個(gè)意思）。比如：table_0/table_1.../table_49
這樣的缺點(diǎn)就是按時(shí)間查詢費(fèi)勁一點(diǎn)。
具體按時(shí)間分表，還是按uid分表，主要看那個(gè)查詢要多一點(diǎn)。

另外，數(shù)據(jù)量都上億了，為什么還考慮mysql呢？可以換ElasticSearch之類的吧。
如果經(jīng)常查詢匯總數(shù)據(jù)，也可以定時(shí)自動(dòng)先把數(shù)據(jù)匯總到一個(gè)表里，便于查詢。

2018年2月10日 16:06

編輯回答

安若晴

統(tǒng)計(jì)類的功能，對(duì)實(shí)時(shí)性和準(zhǔn)確性要求不是特別高，建議新建匯總表，晚上定時(shí)做增量數(shù)據(jù)的匯總更新，通過預(yù)計(jì)算解決性能的問題。

2017年2月8日 15:19

編輯回答

還吻

根據(jù)uid哈希后（或如你所說后四位）分表；支持1，3的查詢
- 優(yōu)勢(shì)：并發(fā)：根據(jù)uid分表，將并發(fā)負(fù)載平攤至各表；如果按時(shí)間分表，那并發(fā)問題無法解決
2的查詢由上表，每日定時(shí)匯總，單獨(dú)計(jì)入一個(gè)表（或分表，按月等）