所以，我有以下问题：
我正在做一些时间序列分析，我有一个类似10 ^ 7身份或ids的模型（例如一个国家/地区的每部手机）。
每个Id都有关联的事件（例如几天），最多可以包含10 ^ 4个事件。对于每个事件和身份，都有不同的“属性”（例如，电话X在当天Y发送的消息数量）。
我正在尝试设计一个mysql数据库来处理这么多信息。我将主要对查询时间分布感兴趣（例如，特定日期的消息数量;或者第X天和第Y天之间的活动电话数量）。
我的第一个虽然是为每个不同的值使用一个表：在每个表上，行是一个标识，每列都有一天。如果有N个不同的属性，那么我会有N个不同的表。这就产生了每个表上有10 ^ 4列的问题;我不确定这是一个好/标准/有效的做法。
我的第二个虽然是一个表有10 ^ 7 * 10 ^ 4行（一个所谓的多对多关系）：第一列有一个主键，第二列有一个身份的id，第三个事件的日子，下一个列是该特定日期该身份的相关属性。
我问你的建议是什么：“由于历史原因”我已经创建了一个非mysql数据库（包含大量的.txt文件），在尝试迁移之前，我想知道它是否真的值得。您可能已经理解，目前我的* .txt数据库中的查询可能会像它可以获得的那样昂贵：我必须通常打开每个.txt对查询执行的操作。对于每个查询，这转换为10-30m。因此，任何低于该限制的建议实际上对我的问题非常有用。
感谢您的时间， 乔治
答案 0 :(得分：0)
您正试图在关系数据库中存储相当的cmoplex信息矩阵。在开始之前，您需要回答以下几个问题：
将项目存储在单独的列中是非启动性的。 MySQL的每行硬限制为4,096列（参见here），小于10 ^ 4。
似乎更规范化的方法是可行的，尽管每行需要id和item id，并且值必须是类型一致的。如果您正在存储数字，没问题。如果某些更好地存储为整数，其他存储为货币值，而其他存储为字符串，则可能会遇到挑战。
我怀疑混合方法可能会奏效。您可能有一些经常使用的项目可以存储在单个表中。使用规范化方法将存储更多项目。然后，您可以考虑使用分区策略来优化访问。
您没有提供足够的细节来设计这样的策略。通常，方法是按时间划分数据。但是，在这种情况下，按项分区数据可能更好，因此可以在分区中获取所有值。