什么时候元组长度太长？答案

【问题标题】：When is tuple length too long?什么时候元组长度太长？
【发布时间】：2017-06-29 23:50:15
【问题描述】：

这是我最大的关系的逻辑架构：

{(id, uName, supplies, score, playerType, storageSupplies, supplyDrop, barracks, armourDepot, hangar, droneHangar, storage, offensive, defensive, infantry, vehicles, air, fuel, explored, morale, cash, population, tax, food, aSector, cSector, iSector, XP)}

如您所见，每个元组都会很长。随着属性的添加，这开始变得非常麻烦。问题是，只有一对一的关系，所以虽然它可以通过将这种关系分解成更小的、元相关的关系来帮助组织并避免混淆，但它不会增加更多的开销吗？或者当这个关系最多有数万个元组时，我是否应该不担心mysql的效率。

【问题讨论】：

10k 行几乎不是问题，即使是最糟糕的查询并且根本没有索引。
那么您个人会将所有这些用户属性放在一张长表中还是将它们组织成几张？
我肯定会从最明显的解决方案开始，是的。没有人能预测到瓶颈，即使是像 twitter 和 facebook 这样庞大的负载项目，在经过大量测量和分析之后，迭代地改进了他们的架构。即使像他们这样聪明的工程师也无法预测未来的问题 - 所以只要问题出现，他们就会解决。

标签： mysql tuples schema

【解决方案1】：

1) 假设您的表最多有 10k 行，很少更新且很少读取（与数据库中的其他实体相比）-您是对的，效率不会有太大的好处，但是...

2) 每一点都很重要；例如，对于这么小的表，其中大部分可以保存在内存中，您将拥有非常快速的 SELECTS；如果很多属性大多是 NULLS，那么拆分表会减少它的大小，并为其他缓存释放 RAM；更新时减少必要的 I/O（通常使事情更具可扩展性）。代价是稍微增加了复杂性（对于更新，SELECTS 可以使用 VIEW）。

3) 拆分一对一关系的“开销”是一种误解；它在很大程度上取决于工作量 - 您可以构建更喜欢将事物分解为两个较小表的案例，并且您可以构建受益于将数据存储在一个表中的案例。

【讨论】：

感谢您的回答。我不确定什么是很少读/写的，但数据库是用 PHP 编程的在线游戏的存储，大多数脚本总是与这个表交互，所以我想说当成千上万的玩家在玩时它可以被大量使用.很好的答案，需要考虑一些很棒的事情。谢谢。
很少读取和写入是与另一个表的相对比较 - 假设玩家移动单位并且每个移动都写入数据库。那将是一个经常被写入的表。或者记录所有玩家的所有行为的表格。与此相比（并且取决于游戏的类型）用户和他们的统计数据可能不需要那么多的阅读和写作。

【解决方案2】：

表的内部表示具有最大行大小 65,535 字节

效率取决于您使用的 MySQL 版本和存储引擎。但是您应该知道，这样做会增加可能不需要缓存的数据。

例如Users表如果我们添加用户的地址数据可能会增加，并且该数据可能不经常需要，因此将其拆分为2个表：Users和Users_address会更有效，因为如果用户表被大量读取，它可以被缓存。

还有其他注意事项，例如维护和索引工作。

【讨论】：