用于优化具有数百万行和多列的表的选项

时间:2014-04-01 08:45:39

标签: mysql sql

我准备将数百万行插入数据库。有一个包含大量列的表比具有多行的多个表更实用吗?

数据类似如下:

  user   Jan01   Jan02   Jan03  ...
abcdef  459232  958394  319348
ghijkl  583941  813941  438923
mnopqr  681294  249393  934304
...

我想过按月拆分它然后我最终会得到大约60张有数百万行的表格。按年分解它仍然会使表格分别产生~365列。如果我要达到那个程度,我想我可能只有一个表,因为它会节省空间并完全删除任何冗余(这在编程中总是很好)。

然而,有一个表〜365 * ~60列的表听起来很疯狂。

是否有某项功能可以解决我不了解的问题?你会做什么?

3 个答案:

答案 0 :(得分:1)

创建一个包含大量行的表。不要被任何事情打破。

如果真的太大了,你可以partition

答案 1 :(得分:1)

你应该让桌子长而不是宽。

如果你做表:

user | date | data

然后你的查询会更快。

您还需要确保正确索引列。

最好不要使用varchar等等,如果可以避免的话 - 如果您知道列的长度并且它始终是integer,那么请确保它是类型:integer Length 11 (或其他)因为这会大大加快查询速度。

修改

让你的表格更容易理解

user       | date       | data

abcdef      Jan01         459232
abcdef      Jan02         958394
abcdef      Jan03         319438
ghijkl      Jan01         583941
ghijkl      Jan02         813941
ghijkl      Jan03         438923
mnopqr      Jan01         681294
mnopqr      Jan02         249393
mnopqr      Jan03         934304

这使您可以更有效地查询数据,更轻松地插入和更新数据,以及数据库的设计方式(长期不宽)。

即使有600万行,它仍然比表格60列宽,100,000行更快。

答案 2 :(得分:0)

我同意其他两张海报 - 桌面效果更好,长度更高"而不是"宽"。

索引,聚簇索引,位图,临时表,锁定,事务日志记录&所有其他年份的研究和数据库的复杂算法被设计用于操作和在垂直维度中选择 - 向下行。

走得更远,你扔掉了使数据库工作的所有机器,并给它带来了良好的性能。

编写365 * 60列可能会超出数据库的最大行数限制;但是如果它没有,那么读/写/更新任何东西都需要访问每个受影响或不排除的行(大约131 KB)。以下是一些让您娱乐的好处:

  • 无法再以递增方式插入数据项;你需要一次写一整行。
  • 索引很大程度上不适用。告别表演。
  • SQL&准备好的陈述退化..现在必须专门针对所涉及的(月,年)专栏生成。
  • 用任何简单的方式告别用户多年来,跨用户等的年度报告。
  • 现在,任何非平凡的查询/报告都需要对整个数据集进行表扫描。你说几百万行?用任何高效的方式告别用户多年来,跨用户等的年度报告。
  • 如果有什么事情会破坏你的数据库的内部缓冲区,日志或事务日志,或者数据库驱动程序 - 这可能是一个很好的找到它:)获得友好的意外技术限制&不寻常的失败案例。

所以,既不容易也不高效:)但值得考虑,因为这有助于给出一个例子和一个例子。了解数据库实际上做了什么。

希望你发现这很有趣!