如何处理 MySQL 中的大表？ （游戏的数据库设计）

Question

假设我有一个 Games 表、一个 Players 表和一个 Users 表。

• 每个游戏都有很多玩家
• 每个玩家都有一个状态，例如“死亡”或“活着”。所以玩家不是用户。
• 每个玩家都有一个用户

到目前为止，结构看起来还不错。但是我想知道，如果一天可能有数千场比赛（这种比赛的持续时间很短），并且每场比赛有 10 或 20 名玩家。我可能会在更少的时间内在 Players 表中获得数百万行超过一年。而且即使在比赛结束后，我也需要将每个球员都保存在桌子上，因为我希望能够重玩任何比赛。我很担心那个时候的性能，选择和更新会越来越慢，对吧？

有什么想法吗？

Answer 1

本质上这是一个可扩展性的问题。因为可扩展性是几乎所有流行的网站、游戏等都会遇到的问题，所以有一系列解决方案。首先，考虑到合理的数据库设计和索引的使用，现代数据库可以很好地处理数百万行数据。如果您的游戏如此受欢迎，以至于数据量超出了现代数据库的处理能力，并且您的企业有一些商业模式，那么您的收入可能足以聘请一流的专家来帮助您解决这个问题。

如果您刚刚开始实施游戏，我建议您将数据库和查询的微调留到以后，性能瓶颈很可能会出现在与您预期不同的地方。不要过早优化:)

Answer 2

是的，经过很长时间，性能方面会出现一些问题，但是对这些表字段进行适当的索引会让您更轻松。

跟踪所有即将对您的表执行的选择和更新查询，并进行适当的索引。

你可以参考How MySQL Uses Indexes和EXPLAIN Output Format

您还可以考虑一些逻辑，将一些游戏或记录在一段时间（如 1 个月或 2 个月）后归档到具有相同结构的另一个表中。