好的，主题行的明显答案是：呃！它是70GB，耐心等待。但是听我说。
我使用mysqlimport快速加载数据文件（mysql标准制表符分隔格式）。 mysqlimport命令完成需要大约4个小时。在此期间，磁盘以容量运行（约50MB /秒磁盘活动）
但是它已经完成了5个小时，我仍然无法运行简单的查询，例如
select * from my_big_table limit 1
当我运行该查询时，它只是无限地阻塞（看似）。没有查询运行，我看到磁盘活动（一个mysql进程运行3MB /秒读取和写入，另一个执行几MB /秒的读取活动），自从我运行mysqlimport以来一直保持不变。我也看到自mysqlimport以来看起来像是一个运行在100％附近的mysql线程。
我的猜测是mysql正在处理索引，例如在背景中（150M记录，InnoDB），这就是阻碍我查询表的能力。但我不知道如何验证或查看正在进行的活动。或在可能完成时做出任何估计。
多余的细节：
我确信有人会质疑为什么一个70GB的表进入mysql。它是Web应用程序中使用的只读数据表。它仅在id上编制索引，查询只会在一组有限的ID上（此表上没有范围查询），只需加入id列并直接查询{{1} }列。该表在一个大型Hadoop作业中更新，并将在每晚使用mysqlimport进行更新以提高效率。
更新：MySQL在70GB导入后最终崩溃，我在错误日志中看不到多少。我已经将表格更改为myisam引擎，并且我再次尝试导入。
错误日志：
id答案 0 :(得分：0)
你只做一件事，而不是编写select * from ..尝试使用
将表的数据划分为多个块（临时查询）后，union 。由于union是一个set操作，它是并行操作。因此，如果您将表格分成5个部分，那么您的数据加载速度至少会加快5倍，如我在问题的答案中所示.. see here
答案 1 :(得分：0)
切换到MyISAM后，我能够更快地加载表格。它加载了表，然后在加载之后又花了几个小时才能运行查询。这主要是因为启用了二进制日志记录，它将两次写入70GB文件，一次写入表，再次写入二进制日志。
我也启用了：
[mysqld]
innodb_file_per_table
这样可以更容易地判断innodb发生了什么。