MySQL 插入分区“p”

这个问题分为三层，取决于我的想法不正确或不可行的地方：

我想通过 id（自动递增）创建 TABLE STOCKS (id,date,symbol,...) HASH PARTITION，并创建 663 个分区。或 CREATE TABLE STOCKS (date,...) 按日期哈希分区，663 个分区。

我应该选择哪个选项？ [PS：663 个分区，因为 stockdata 是 13 年 * 每年 51 周]

有没有办法选择一个特定的哈希分区来插入行？如：对于表 'stocks'，在 'id' 列（664 个分区）上分区的 HASH 可以执行以下操作：插入分区 p52 VALUES(...)
如果 2 是可能的，可以对 LOAD DATA IN FILE A.csv 做同样的事情，使得 .第 1-2000 行转到分区 p0 .行 2001-4000 转到分区 p1... .等等。

[我假设如果我指定要插入的分区，插入会更快。我过去直接在分区表上尝试插入语句，因为 INSERT INTO stock VALUES(..) 与未分区的股票表相比非常慢。]

不要使用Hash分区；它要么没有任何好处（进行点查询时），要么效率极低（进行范围查询时）。

如果日期+符号为UNIQUE，则去掉id；这是不必要的负担。假设，然后使用

PRIMARY KEY(symbol,date),INDEX(date)

二级索引是可选的 -- 仅当您确实需要按 date 搜索而不指定 symbol 时才包含它。

考虑将 symbol 规范化为 symbol_id，其中它是 SMALLINT UNSIGNED，以便符号仅使用 2 个字节。

您为什么担心 INSERT 速度？这是一次性任务，不是吗？

你的数学听起来像是一张相当小的表格——13512000 = 1.3M 行——也许是 100-200MB。

附注。在这 52 周中，您将离开哪一个？

更新

如果您每天添加更多行，负载将小得多，并且需要不同的技术。特别是，您可能只有一个包含当天收盘价的文件，而不是 2000 个文件？

如果数据实际上超过 100GB，并且您从 13 年的数据开始，我建议如下：

PARTITION BY RANGE(TO_DAYS(date))

并从以下分区开始（甚至在执行 LOAD 之前）：

每天晚上检查是否应该添加新的月份，在这种情况下，ALTER TABLE REPARTITION future 到下个月和一个新的（空的）“未来”。

这种奇怪的分区设置的原因：每天晚上加载新数据时，它会在当前“月”分区中命中2000个不同的位置；这可能会适合缓存，从而避免抖动。

并且初始加载的每个 LOAD DATA 都会在巨大分区中的一个位置加载大量数据，同样是高效的。