MySQL LOAD DATA INFILE：サーバーの改善、パフォーマンスの低下
MySQL用のMicrosoftAzureデータベースをテストしていますが、理解できないパフォーマンスの問題が発生しました。
私は1コアの「ベーシック」サーバー（2 GB RAM、「スタンダードストレージ」）を起動しました。データベースとテーブルを作成し、LOAD DATA INFILEを使用して約400万行（30 GB）をインポートしました。 56分かかりました。
次に、8コアの「メモリ最適化」サーバー（80 GB RAM、「プレミアムストレージ」）を起動しました。まったく同じタスクを繰り返し、まったく同じファイルをロードしました。今回は7時間16分かかりました。
より良いサーバー、はるかに悪いパフォーマンス（このタスクで）-私が期待していたものではありません。間違いがないことを確認するために、上記の手順を繰り返しましたが、ほぼ同じ結果が再び得られました。
問題は、メモリ最適化サーバーのデフォルトサーバーパラメーターが基本サーバーとは異なるため、このタスクの実行が遅くなることだと思います（Azureが設定するデフォルトからパラメーターを変更していません）。しかし、どのパラメータが原因かはわかりません。誰かがこの問題について洞察を持っているなら、私はそれをいただければ幸いです。
基本的なサーバーパラメータ： http://Pastebin.zone/wRniyPm6
メモリ最適化サーバーパラメータ： http://Pastebin.zone/phuDcZj4
この動作を引き起こしていると思われるものは次のとおりです。
Azureのドキュメント によると、Azureの基本層サーバーには「可変」IOPSが付属していますが、メモリ最適化サーバーには、データベースサーバーに割り当てられたストレージの量に基づく固定IOPSが付属しています。
メモリ最適化サーバーに100GBを割り当てました。これにより、Azureの3 IOPS/GBの比率に従って、300 IOPSになります。
おそらく、Basicサーバーの「可変」IOPSは、MemoryOptimizedサーバーの300IOPSを大幅に上回っています。
教訓：Azureデータベースで高速なストレージアクセスを取得するには、サーバーに十分なストレージ容量を割り当てる必要があります（それほど多くのストレージが必要ない場合でも！）。
数百万行のデータをロードするときのAWS Paramenters Groupへの提案
innodb_change_buffer_max_size=50 # from 25 for improved LOAD speed during high volume process
完了したら、通常の操作の必要性に応じて、25％（またはそれ以下）に戻します。
メモリ拡張インスタンスで、
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
次のテストでは、これらにより経過時間が短縮されます。