很多資料量的使用者積分變動明細有什麼好的儲存方案？

一個使用者量在600萬層級的網站，一個使用者一天最多可能產生30條積分增加，比如+1,+2,+5.也可以產生若干條積分支出,比如-50,-100。
有什麼好的方案可以儲存使用者的這些變動明細？mysql似乎不是一個好的方案，因為資料量實在太大了。

回複內容：

一個使用者量在600萬層級的網站，一個使用者一天最多可能產生30條積分增加，比如+1,+2,+5.也可以產生若干條積分支出,比如-50,-100。
有什麼好的方案可以儲存使用者的這些變動明細？mysql似乎不是一個好的方案，因為資料量實在太大了。

我給題主算算，假定所有使用者都是活躍的，而且全都每天有30條積分增加，那麼每秒的請求數計算如下：

600w * 30 = 18000w18000w / 86400秒 = 2083條/秒

據我所知，就這點請求量，MySQL完全扛得下來，但你必須對使用者ID做索引。

事實上線上肯定不可能有這麼多請求量的，600w使用者層級的網站，裡面活躍使用者不會太多，也不可能每個使用者每天都有30條增加，這裡的量會比這裡預估的少很多(估計少一半都不止)。

所以建議題主先仔細分析資料，不要拍腦袋，搞premature optimization。

如果題主希望瞭解 MySQL 的效能，這裡有個官方頁面供參考：https://dev.mysql.com/tech-resources/articles/mysql-5.6.html

樓主可以考慮用redis來儲存使用者積分 然後每天對積分進行統計 然後存入MySQL

部分取決於DBA團隊精通哪些工具，儲存類的應用一坦出問題，要能快速恢複。如果團隊主要用mysql那先還是要考濾用mysql。

