MySqlDumpのDISABLE KEYSはインポートに影響しません

Inno-Tablesでのインポート速度に関する私の前の質問のフォローアップがあります（驚き！）。

シナリオ
私は妥当な時間内にローカルの開発用マシンにいくつかのbig *データベースダンプをインポートしようとしました。KEYテーブルに接続されている多くのがボトルネックになっていますが、それでもライブシステムにとって重要です。

上記の質問をした後の私のアプローチはKEY ...、ダンプからステートメントを削除し、キーをインポートして再度追加することでした。

しかし、現在のダンプを編集してローカルにインポートすることがよくあり、これらの面白い "コメント"に遭遇しました（- disable/enable keys行）。

--
-- 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)'ダンプからすべての-line を削除し、ダンプをインポートして、ADD KEY 'foo' ...後でスクリプトを実行する場合と同じ動作だと思います。

私が観察した
ことキーを手動で削除し、キーをインポートして再度追加しDISABLE KEYSてから、作成した条件ステートメントに依存する方がはるかに高速ですmysqldump

ダンプの手動編集+ mysqlインポート+キーの追加= 15 + 8 + 8≈30分
プレーンmysqlインポート：あきらめました（1日8時間だけ支払います> :)）

私は仕方がないのですが、ここで非常に基本的な何かが欠けていると思います（またはデータベースが私を荒らしています）。

あなたはに頼ることはできませんDISABLE KEYS;し、ENABLE KEYS;それがInnoDBストレージエンジンで実装されていないため、InnoDBのために。ランニングALTER TABLE ... DISABLE KEYS;とALTER TABLE ... ENABLE KEYS;MyISAMのために設計されていました。それはのためのMySQLドキュメントALTER TABLEで言うように：

MyISAMテーブルでALTER TABLEを使用する場合、一意でないインデックスはすべて、別のバッチで作成されます（REPAIR TABLEの場合と同様）。これにより、多数のインデックスがある場合に、ALTER TABLEがはるかに高速になります。

MyISAMテーブルの場合、キーの更新を明示的に制御できます。ALTER TABLE ... DISABLE KEYSを使用して、一意でないインデックスの更新を停止するようMySQLに指示します。次に、ALTER TABLE ... ENABLE KEYSを使用して、欠落しているインデックスを再作成します。MyISAMは、キーを1つずつ挿入するよりもはるかに高速な特別なアルゴリズムを使用してこれを行うため、一括挿入操作を実行する前にキーを無効にすると、かなりのスピードアップが得られます。ALTER TABLE ... DISABLE KEYSを使用するには、前述の特権に加えてINDEX特権が必要です。

非一意性インデックスは無効になりますが、SELECTやEXPLAINなどのステートメントを使用しない場合は無視されます。

InnoDBについては言及されていません。 ALTER TABLE ... DISABLE/ENABLE KEYS;

ALTER TABLE ... DISABLE KEYS;InnoDBテーブルに対して実行した場合でも、警告が生成されます。

mysql> show create table mytimes\G
*************************** 1. row ***************************
       Table: mytimes
Create Table: CREATE TABLE `mytimes` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `totalTime` int(11) NOT NULL,
  `totalTimeDesc` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> alter table mytimes disable keys;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> show warnings;
+-------+------+-------------------------------------------------------------+
| Level | Code | Message                                                     |
+-------+------+-------------------------------------------------------------+
| Note  | 1031 | Table storage engine for 'mytimes' doesn't have this option |
+-------+------+-------------------------------------------------------------+
1 row in set (0.00 sec)

mysql>

そのため、影響はありません。@jynusが箇条書き7の回答で同じことを述べたことを思い出してください。

MyISAMはデータとインデックスを2つの別々のファイル（データの場合は.MYD、インデックスの場合は.MYI）に保持するため、インデックスを無効または有効にするのは簡単です。InnoDBは、（クラスタ化インデックスを介して）PRIMARY KEYと行データを同じInnoDBページに保持します。セカンダリインデックスは、すべてのセカンダリインデックスリーフエントリへのアタッチメントとしてPRIMARY KEYを保持します。データとインデックスは、クラスタ化インデックスを経由して絡み合っているので、誰もが、まだのように、実装しようとしていないDISABLE KEYSとENABLE KEYSInnoDB内で。