MySQL INSERT... 选择包含 4.2 亿条记录的大型数据集

Question

我有一个包含大约 4.2 亿条记录的大型数据集，我能够使用 LOAD DATA INFILE 语句在大约 15 分钟内将它们及时加载到临时表中。我需要这个临时表来暂存数据，因为我在将其加载到最终目的地之前对其进行了一些清理。

临时表定义为：

CREATE TABLE `temporary_data` (
  `t_id` smallint(10) unsigned NOT NULL,
  `s_name` varchar(512) NOT NULL,
  `record_type` varchar(512) NOT NULL,
  `record_value` varchar(512) NOT NULL
) ENGINE=MyISAM;

需要加载此数据的目标表称为my_data，其定义为：

CREATE TABLE `my_data` (
  `s_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `t_id` smallint(10) unsigned NOT NULL,
  `s_name` varchar(63) NOT NULL,
  PRIMARY KEY (`s_id`),
  UNIQUE KEY `IDX_MY_DATA_S_NAME_T_ID` (`t_id`,`s_name`) USING BTREE,
  KEY `IDX_MY_DATA_S_NAME` (`s_name`) USING BTREE,
  CONSTRAINT `FK_MY_DATA_MY_PARENT` FOREIGN KEY (`t_id`) REFERENCES `my_parent` (`t_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

问题是，将临时表中的数据加载到my_data 的查询非常慢，因为我怀疑这是因为my_data 包含两个索引和一个主键。到目前为止，这个查询已经运行了 6 个多小时：

INSERT IGNORE INTO my_data (t_id, s_name)
SELECT t_id, s_name
FROM temporary_data;

我需要确定一种方法来加快此查询的速度，以便及时完成（最好在 30 分钟内完成）。

我考虑过的一些方法：

1. 禁用索引：我可能能够通过禁用/删除IDX_MY_DATA_S_NAME 索引而侥幸成功，但我依靠唯一索引 (IDX_MY_DATA_S_NAME_T_ID) 来保持数据清洁。这是一个每天都会自动运行的过程，不可避免地会有一些重复。另外，当我再次启用索引时，在这么大的数据集上重建索引似乎同样耗时。
2. 使用 DATA OUTFILE： 将清理后的数据直接导出并重新导入到 my_data。我在某处看到了这个推荐，但在考虑之后，索引/PK 仍然是重新插入的争论点。
3. 交换表格： 将 my_data 替换为 temporary_data 听起来很吸引人，但该表格对于 s_id 字段有很多外键关系，因此我希望确保这种方法值得麻烦禁用外键并重新启用它们。子表包含的记录将明显少于my_data，因此在这方面重新启用外键可能可以忽略不计。
4. LOAD DATA INFILE directly: 使用语句的 SET 部分中的条件将数据直接加载到 my_data 以使所有字段 NULL 当它不符合我最初应用于 @ 的清理标准时987654338@ 在将其加载到 my_data 之前。这很 hacky，但它依赖于假设 LOAD DATA INFILE 将比 INSERT 更快... SELECT 即使面对索引，由于表上的唯一约束，在运行后只会删除一行空值.

这些听起来都不是非常棒的想法。如果有人有任何提示，我会全力以赴。

Answer 1

去掉s_id，估计没用了。然后推广UNIQUE(t_id, s_name) to be thePRIMARY KEY`。这减少了为插入的每一行执行的测试次数。

考虑禁用FOREIGN KEYs；毕竟，他们需要执行可能是多余的检查。

INSERT IGNORE INTO my_data (t_id, s_name)
    SELECT t_id, s_name
    FROM temporary_data
    ORDER BY t_id, s_name;  -- Add this

这样，插入不会在目标表中跳跃，从而（希望）避免大量 I/O。

你在增加桌子吗？还是换掉？如果替换，有更好的方法。

更多...

您是否注意到INSERT IGNORE 为每一行未插入的行浪费了一个AUTO_INCREMENT 值？让我们尝试另一种方法...

INSERT INTO my_data (t_id, s_name)
    SELECT t.t_id, t.s_name
        FROM temporary_data AS t
        LEFT JOIN my_data AS m  USING(t_id, s_name)
        WHERE m.s_id IS NULL
        ORDER BY t.t_id, t.s_name;

ORDER BY 避免在INSERT 期间跳来跳去。
LEFT JOIN 将活动限制为“新”行。
不会销毁任何 AUTO_INCREMENT 值。

每次将插入多少行？如果是数百万，那么最好将其分成块。请参阅我的discussion 分块。它可能比建立一个巨大的撤消轨迹最终折腾更快。

进一步讨论 -- 给定

my_data:  PRIMARY KEY(s_id)  -- and s_id is AUTO_INCREMENT
my_data:  INDEX(t_id, s_name)
INSERT...SELECT...ORDER BY (t_id, s_name)  -- same as index

这些是有效的：

• 由于ORDER BY 和二级索引相同，索引的添加将高效完成。
• 同时，新的AUTO_INCREMENT 值将在表格的“末尾”按顺序生成。

如果(t_id, s_name) 是唯一的，那就更好了。那我们可以考虑彻底去掉s_id，把两个索引改成这个：

PRIMARY KEY(t_id, s_name)

如果其他表引用s_id，这将是一个问题。 可能的解决方法是保留 s_id 并拥有

PRIMARY KEY(t_id, s_name)
INDEX(s_id)   -- sufficient for AUTO_INCREMENT

我对大局和其他查询的了解不够，无法判断要采取的方向。所以我最初的建议（在“进一步讨论”之前）是“保守的”。