问题描述
这个问题分为三层，取决于我的想法不正确或不可行的地方：
我想通过 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 到下个月和一个新的（空的）“未来”。
更多详情：http://mysql.rjweb.org/doc.php/partitionmaint
这种奇怪的分区设置的原因：每天晚上加载新数据时，它会在当前“月”分区中命中2000个不同的位置；这可能会适合缓存，从而避免抖动。
并且初始加载的每个 LOAD DATA 都会在巨大分区中的一个位置加载大量数据，同样是高效的。