我的博客类型网站上有一个积分系统，用户可以通过不同的方式（评论/对帖子投票/对评论投票等）做出贡献来赚取积分。我将如何有效地记录用户在 MySQL 数据库中获得的所有积分。
目前我正在考虑在它自己的表中包含以下字段：
post_id,
giving_user_id,
receiving_user_id,
type,
date_added
现在，很明显，如果我的网站增长并且我有 100 万……5 亿……10 亿行，如果数据类型设置正确，这种方法和结构是否能够持续运行而无需永远运行？
我主要只是插入表格，但希望它能够在未来显示之前的 20（示例）积分奖励/扣除，类似于 stackoverflow 用户统计页面。
是否有更有效的结构对我更好？
更新信息
是的，它在功能上非常类似于 stackoverflow，一个用户每个 postid 获得一票。@Paul Gregory 重新考虑后删除receiving_user_id可能是一个更好的主意，因为它几乎总是与帖子相关。
假设您可以使用 post_id 来识别特定评论，并且您正在type合理地使用（作为与您的其他 ID 一样的数字），那么这种方法对于日志来说非常完美。
（我不知道究竟是什么receiving_user_id告诉我们我们不知道的post_id——我希望你不要指望它能区分帖子和评论）。
但是，如果您要在每次需要时使用该表来计算总分，则效率不会很高。
因此，您应该单独存储当前总数 - 针对每个帖子/评论。
由于您只想显示最后 20 点，因此您应该编写一些导出日志数据并每隔一段时间删除旧日志条目的内容。
On my website I keep a point log, and basing on that I recalculate daily a summary for a given period of time. To have always current summary value, I also add the proper value to a current day/month/year sum when new entry is recorded.
About querying - with proper database indexing by date, you can achieve a decent performance even for large point logs.
If I was you I would have a table called points which lists the amount of points that can be awarded for a certain actions. The structure might look something like this,
point_id INT PRIMARY_KEY
name VARCHAR
descriptions TEXT
number_of_points INT
Then you can have a table called user_points where you can record when users performed actions that gave them points. This table would look something like
point_id INT
user_id INT
date DATE
There could be better ways of doing it but thats what I suggest based on the information you've provided.
Hope that helps
从您的 POST 表中删除这些字段并创建一个非常相似的表并创建 InnoDB 外键关系：
id (log id)
post_id, (add relation with your post table post.id)
giving_user_id, (user id relation)
receiving_user_id, (user id relation)
type, (type as you want);
date_added (datetime or whatever);
通过这种方式，您将规范化您的表格，并且您将更好地控制您的数据和日志记录。