我正在考虑构建像《炉石传说》一样的在线纸牌游戏。玩家将有无限的存货来存储他们拥有的所有卡。
使用这种方法，对于每个玩家卡组合，其数据量将非常多，因此每行将成倍增长。
最初，我希望有3张桌子：
A Player_Table
| Player_ID | Player_Name | Rank | Icon | ect...
A Card_Table
| Card_ID | Card_Name | Attack | Defence | ect...
然后是他们的库存表
| Player_ID | Card_ID | Quantity |
然后，我可以使用类似SELECT Card_ID FROM Inventory_Table WHERE Player_ID = YourID的语句
很明显，这里存在一个扩展问题，我添加的卡越多，加入的玩家越多，获取卡列表所需的时间就越长。
[我当时正在考虑使用像MongoDB这样的NoSQL替代品来解决可能引起的潜在性能问题，但是后来我发现它不像mySQL那样不免费用于商业用途，因此我放弃了该计划。
我想到的第三个也是最后一个想法是动态添加表。创建玩家（创建帐户）时，我可以添加一个名为“ Player_Cards _” + Player_ID的表格（例如Player_Cards_318），这告诉我这是个坏主意，但我不确定。
[请有人可以向我指出正确的方向。
很明显，这里存在一个扩展问题，我添加的卡越多，玩家越多加入时间越长，您的卡片清单就会越多。
不，不是您想的那样。假设您使用索引，则增长将是对数的-不是线性的。更像是“两倍于条目的25倍”。
我正在考虑使用像MongoDB这样的东西作为NoSQL替代品来帮助这可能导致的潜在性能问题
不。正如我所说的，除了性能问题主要是一种幻觉之外，nosql对关系问题并不是特别有用，到目前为止，您还展示了一个现实问题;）
我想到的第三个也是最后一个想法是动态添加表。当一个球员是创建（创建帐户）
[这对在公司工作的任何人都是一种严重的罪行。从根本上讲，它使大量分析完全无法使用，并且导致很多小表通常是反模式的（数据库尚未为此进行优化，因此您最终将开始浪费资源以寻求解决方案，任何专业团队都会让您看到门。
使用解决方案1，完成。您的可配置性问题并不像您薄一样糟糕（尤其是如果您添加了一个分割层），而且由于缺少用户，您可能根本不会遇到它。
表中的数百万行通常不是问题。数十亿行变得令人兴奋，但不一定不可能。请进行数学运算，并给出一个粗略的估计。
同时，请提供SHOW CREAETE TABLE，以便我们了解所涉及的数据类型，引擎和索引。
不要为每个用户（或每个其他对象）创建一个新表。这是一个经常被问到的问题。答案始终是“否”。
SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID
是非常基本的查询。任何带有Player_ID的索引starting将允许非常快地（毫秒）执行该查询。 INDEX(Player_ID, Card_ID)可能会更快。您还有哪些其他常见查询？
缩放...一个简单的经验法则是“每行100个字节”。计算所有表中所有行所需的字节数；那会适合您的磁盘吗？ （我怀疑会的。）
您将在一个SELECT中进入这些表的2或3。因此，学习如何执行SQL JOIN。