在 MySQL 中将一个大表拆分为多个表或坚持一个表是否更有效？答案

【问题标题】：Is it more efficient to split a large table into several tables, or stick with one, in MySQL?在 MySQL 中将一个大表拆分为多个表或坚持一个表是否更有效？
【发布时间】：2015-08-23 10:09:58
【问题描述】：

我正在编写一个 C# 程序，我正在查看大约 5300 个股票代码。我将数据存储在 MySQL 数据库中，其中包含以下字段：日期、股票名称、收盘价、movingaverage50、movingaverage200、...以及其他一些字段。每只股票最多可以有 15300 个不同的数据点。所以整个数据库将是 5300x15300x6 左右不同的字段。

我的问题是，除了一张大表之外，还有没有更有效的方法来存储所有这些数据？将数据分成不同的表格，比如十年，能给我带来什么吗？是否有一些链接/网站可以让我大致了解在设计数据库时应该考虑哪些注意事项以尽可能快，或者 MySQL 数据库本身是否使其高效？

我目前正在一次读取 5500 个 excel 文件，以用数据填充我的 c# 对象，这大约需要 15 分钟...我假设一旦我的 MySQL 运行起来，这将大大减少。

感谢您的帮助；我猜这更像是寻找一个开始思考数据库设计的地方。

【问题讨论】：

看看分区

标签： mysql database-design

【解决方案1】：

评论太长了。

一般来说，以相同格式存储多个表是个坏主意。这成为一个维护问题，并对某些类型的查询产生可怕的后果。所以，一张桌子是首选。

总行数为 486,540,000。这是相当大的，但并不特别。

关于数据布局的问题不仅取决于数据，还取决于数据的使用方式。我的猜测是使用索引和分区可能会解决您的性能问题。

在 15 分钟内处理 5,500 个 Excel 文件似乎相当不错。数据库是否会明显更快取决于服务器和应用程序之间的数据量。如果您将“Excel”文件作为 CSV 文本文件读取，那么数据库可能不会有很大的收获。如果你是通过 Excel 阅读，那可能会更好。

注意：使用数据库，您可以将处理从 C# 移到数据库中。这使数据库能够利用并行处理，从而为提高性能开辟其他途径。

【讨论】：

【解决方案2】：

一张桌子。
PRIMARY KEY(ticker, date) -- 由于集群，这使得获取有关单个股票代码的历史信息变得高效。
PARTITION BY (TO_DAYS(date)) -- 这导致所有INSERT 活动都在一个分区中。这个分区的大小是有限的，因此每天晚上随机访问以插入 5300 条新行分散在各处可能仍会在缓存中。
按月分区，或者大约是那个大小的分区——小到足以缓存一个分区，但又不会小到你有大量的分区。（最好将表保持在 50 个分区以下。这种“限制”可能会随着 5.7 中的“本机分区”而解除。）
如果您已经在一个表中有几个月的数据，请将其放在一个超大的分区中；按月拆分没有任何好处。
最小化列大小。 ticker_id 的 2 字节 SMALLINT UNSIGNED，链接到代码规范化表。 3字节DATE；等等。对于INT UNSIGNED，音量可能太大，要么使用FLOAT（有一些舍入错误），要么使用一些DECIMAL。价格很棘手 - FLOAT 舍入错误，DECIMAL 大小过大：美国股票代码至少需要 (9,4) (5 个字节)，如果你回到分数定价时代（例如，5-9/16 )。
考虑移动平均线的计算；这可能是最密集的活动。

【讨论】：