我构建了一个分析引擎，从我的数据库中提取50-100行原始数据（让我们称之为raw_table），在PHP上运行一系列统计测量，然后提出140个数据点然后需要存储在另一个表中（让我们称之为results_table）。所有这些数据点都是非常小的整数（“40”，“2.23”，“ - 1024”是数据类型的好例子。）
我知道mysql的最大列数非常高（4000+）但是当性能真正开始降低时，似乎会出现很多灰色区域。
这里有一些关于最佳性能实践的问题：
1）如果更好，140个数据点可以分成20行7个数据点，如果更少的列更好，则全部具有相同的“experiment_id”。但是我总是需要拉动所有20行（每行7列，加上id等），所以我不认为这比拉动1列140列更好。所以问题是：最好存储20行7-9列（这些都需要一次拉出）或1行140-143列？
2）鉴于我的数据示例（“40”，“2.23”，“ - 1024”是将要存储的内容的好例子）我正在考虑结构类型smallint。那里的任何反馈，表现方面还是其他方面？
3）欢迎任何有关mysql性能问题或提示的其他反馈。
提前感谢您的意见。
答案 0 :(得分：4)
我认为存储更多行（即标准化）的优势取决于面对变化时的设计和维护考虑因素。
此外，如果140列具有相同的含义或每个实验有所不同 - 根据规范化规则正确建模数据 - 即数据如何与候选键相关。
就性能而言，如果使用所有列，它会产生很小的差异。有时，对于大量数据，pivot / unpivot操作可能是昂贵的，但它对单个密钥访问模式几乎没有什么区别。有时，数据库中的数据透视表可以使您的前端代码更加简单，并且在变更时后端代码更加灵活。
如果你有很多NULL，可能会消除规范化设计中的行，这样可以节省空间。我不知道MySQL是否支持稀疏表概念，这可能会在那里发挥作用。
答案 1 :(得分：3)
每次都有140个数据项，每个都是double类型。
它不是实际的区别，无论是1x140还是20x7还是7x20或4x35等。当然，对于一种形状来说它可以无限快，但是你考虑到PHP代码中的额外复杂性处理不同的形状。
您是否有经过验证的瓶颈，或者这只是随机的过早优化？
答案 2 :(得分：3)
您没有建议您打算在数据库中存储大数据，但出于此参数的目的，我假设您有10亿（10 ^ 9）个数据点。
如果将它们存储在140列中，则只有7行，但是，如果要从大量实验中检索单个数据点，则必须获取大量非常宽的行
这些非常宽的行将占用你的innodb_buffer_pool中更多的空间，因此你将无法缓存这么多;当你再次访问它们时，这可能会减慢你的速度。
如果每行存储一个数据点，在列数很少的表（experiment_id，datapoint_id，value）中，则需要拉出相同数量的较小行。
但是，行的大小对所需的IO操作数量几乎没有影响。如果我们假设您的10亿个数据点不适合ram（现在这不是一个安全的假设），那么结果性能可能会大致相同。
使用少量列可能是更好的数据库设计;但是如果使用大量的列，它将使用更少的磁盘空间并且可能更快填充。