我正在努力批量导入一个由大约 1000 万行（或 7GB）组成的相当大的 InnoDB 表（对我来说这是迄今为止我使用过的最大的表）。
我做了一些研究如何提高 Inno 的导入速度，目前我的设置如下所示：
/etc/mysql/my.cnf/
[...]
innodb_buffer_pool_size = 7446915072 # ~90% of memory
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 5000
innodb_thread_concurrency=0
innodb_doublewrite = 0
innodb_log_file_size = 1G
log-bin = ""
innodb_autoinc_lock_mode = 2
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_instances=8
import is done via bash script, here is the mysql code:
SET GLOBAL sync_binlog = 1;
SET sql_log_bin = 0;
SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
SET SESSION tx_isolation='READ-UNCOMMITTED'; …我对我之前关于 Inno-Tables 的导入速度的问题进行了跟进（惊喜！）。
场景
我尝试在合理的时间内在我的本地开发机器上导入一些大* 数据库转储。我们有很多KEY附加到表的s 已经证明是一个瓶颈，但对我们的实时系统仍然很重要。
在提出上述问题后，我的方法是KEY ...从转储、导入和重新添加密钥中删除语句。
但是，我经常发现自己编辑当前转储以将其导入到本地，并且偶然发现了这些有趣的“评论”（disable/enable keys-lines）
--
-- Dumping data for table `monster`
--
LOCK TABLES `monster` WRITE;
/*!40000 ALTER TABLE `monster` DISABLE KEYS */;
INSERT … INSERT … INSERT
/*!40000 ALTER TABLE `monster` ENABLE KEYS */;
UNLOCK TABLES;
但实际上这些“注释”是有条件的 MySql-Statements
这对我来说是新闻，但好吧，考虑到输出形式mysql --version，我觉得一切都很好：
mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.3
我的假设
表已锁定（很好，只有我在开发机器上）。然后禁用表模式中定义的键，导入数据，启用键。
因此，在“数据插入”阶段，不应将时间浪费在键上，而是在插入所有数据后进行检查。
我会认为这与我KEY 'foo' (foo)'从转储中删除所有 - …