噂、意見、伝聞、事実、バージョン関連のベンチマーク、個人的な経験など...

複数のスレッドによりスループットが向上しますが、制限があります:

• スループットの上限は理論上の制限の約半分です。 (あなたの「パーセンテージ」) (これはマルチスレッド パッケージに基づくベンチマークです。名前は忘れました。10 年前のことです。)
• 複数のスレッドは、ミューテックスやその他の必要なロック メカニズムに関して互いに競合します。
• 5.7 あたりから、MySQL のマルチスレッドの制限は 64 スレッドになり、この値を超えるとスループットが停滞するか、さらには低下します。 (出典: 多くの Oracle ベンチマークは、あるバージョンが以前のバージョンよりも大幅に優れていることを誇っています。) (一方、スレッドごとのレイテンシーは桁外れに大きくなっています。)
• 可能であれば、各スレッドはデータをバッチで処理する必要があります。

LOAD DATA
• は、単一スレッドから一度に多数の行を INSERT する最速の方法です。ただし、ファイルを LOAD に書き込むコストを含めると、一括挿入よりも遅くなる可能性があります。 BULK
INSERT
• が続きます。ただし、特定の制限または「利益逓減」に達すると、行数は「数百」に制限されます。 バッチ挿入は、
INSERT
• クエリごとに 1 行を挿入するよりも 10 倍高速です。したがって、これ (または LOAD DATA) は高速取り込みに使用する価値があります。 (出典: 多数の 異なる 時間制限テスト)
データソース:

• データ収集に関するディスカッション:
http://mysql.rjweb.org/doc.php /staging_table
データをロードした後はどうなりますか?もちろん、これは書き込み専用のテーブルではありません。

#標準化を参照してください
• パーティショニング
最終的に古いデータを消去することを除いて、ほとんど役に立ちません。
• #パーティションを参照してください。 巨大な「ファクト」テーブルは検索が困難です。取り込むときに概要データを構築することを検討してください: 概要テーブル
• 上記の処理を行った後、元のデータを破棄することもできます。 1 日あたり 1 テラバイトのデータを取得しているようです。