如何处理MySQL中的大表?(游戏的DB设计)


How to deal with big tables in MySQL? (DB design for a Game)

假设我有一个游戏表、一个玩家表和一个用户表。

    每个游戏有很多玩家每个玩家都有一个状态,比如"死"或"活"。所以玩家不是用户。
  • 每个玩家都有一个用户

到目前为止,结构看起来很好。但我想知道的是,如果每天有成千上万的游戏(这种游戏持续时间很短),每个游戏有10或20个玩家……在不到一年的时间里,我可能会在Players表中拥有数百万行。即使在游戏结束后,我也需要将每个玩家保存在表中,因为我希望能够重玩任何游戏。我担心的是性能,选择和更新会越来越慢,对吧?

任何想法吗?

本质上这是一个可伸缩性问题。因为可扩展性是几乎所有流行的网站、游戏等都会遇到的问题,所以有一系列的解决方案。首先,给定合理的数据库设计和索引的使用,现代数据库可以很好地处理数百万行数据。如果你的游戏非常受欢迎,以至于数据的增长超出了现代数据库的处理能力,并且你的企业有一些商业模式,那么你可能会赚到足够的钱来雇佣顶尖的专家来帮助你解决这个问题。

如果你刚刚开始执行游戏,我建议你把数据库和查询的微调留到以后,很可能性能瓶颈会出现在不同的地方,而不是你期望的地方。不要过早优化:)

是的,在很长一段时间后,会有一些关于性能的问题,但是对这些表字段进行适当的索引将使您更容易。

跟踪表上所有即将到来的select和update查询,并做适当的索引。

你可以参考MySQL如何使用索引和EXPLAIN输出格式

你也可以考虑一些逻辑,在一段时间后(如1个月或2个月)将一些游戏或记录归档到具有相同结构的另一个表中。