web-dev-qa-db-ja.com

1つの単一の挿入MySQLに複数の行を挿入する場合

pythonスクリプトを使用して、複数行挿入メソッドを使用してMySQLで一括挿入を実行しました。私のテストcsvファイルは100,000行のみで構成されています(実際の行は数百万行で構成されています)。挿入。

unix timeコマンドを使用すると、結果は次のようになります。

for 10 lines            100 lines               1000 lines 

user 13.675 seconds     user 11.948 seconds     user 9.908 seconds  
sys  0.192 seconds      sys  0.076 seconds      sys  0.080 seconds

for 10,000 lines        100,000 lines    

user 11.672 seconds     user 12.024 seconds 
sys  0.072 seconds      sys  0.079 seconds

より簡単にするために、ユーザー+ sysを追加すると、結果は

10 rows           13.867 seconds
100 rows          12.024 seconds
1000 rows         9.988 seconds
10000 rows        11.744 seconds
100,000 rows      12.103 seconds

私は、複数行の挿入が500〜1000行程度の方が優れ、500行未満および1000行を超えると生産性が低下する主な理由を理解しようとしています。インターネットで検索したところ、別の答えが見つかりました。一部はそれが依存していると述べています

max_allowed_packet, bulk_insert_buffer_size, key_buffer_size .

これらのパラメーターを試しましたが、効果がまったくわかりません。

私の質問は、一括挿入が挿入あたり500行から1000行の間で最適である理由と、この範囲以外のカウンター生産性であり、主な要因は何ですか?私はすでにこの設定を使用しています

 max_allowed_packet=16M

いくつかのパラメータもあります。

Table     Non_unique Key_name  Seq_in_index  Column_name  
roy_table    0       PRIMARY   1                id

Collation Cardinality  Sub_part  Packed  Null  Index_type
 A       100650        NULL     NULL           BTREE

一部の機関は、一括挿入の効率性に関するベンチマーク、またはこれが特定のポイントを超えて非生産的である理由にどのように対処できるかについてのアイデアを指摘できますか?私は自分の報告で明確な理由を示さなければなりませんでした。私はどんな小さなヒントやアイデアにも本当に感謝します。ありがとう

2
roy
  • CPU時間ではなく経過時間の方が興味深いです。
  • クライアントの時間を測定しており、サーバーの時間を測定していません。
  • serverには、大きなチャンクに対して「悪い」結果となる多くの要因があります:バッファー、元に戻すログ、レプリケーションの遅延など。
  • 解析時間は、短いチャンクの(サーバー上の)主なオーバーヘッドです。
  • 行サイズを指定していません。これは、クライアント、ネットワーク、およびサーバーにいくらかの影響を与えます。
  • クライアントとサーバー間の接続は何ですか?ソケット? LAN? WAN?それらの間の待ち時間はどれくらいですか? WANでは、ネットワーク遅延はおそらく他のすべての考慮事項を圧倒します。
  • `key_buffer_sizeはMyISAMにのみ適用されます。そのエンジンを使用していないことを願っています。
  • テーブルにインデックスはありましたか?もしそうなら、何ですか?たとえば、PRIMARY KEYはUUIDであり、大きな影響を与える可能性があります。また、UNIQUEキーは重複をチェックする必要があります。 (繰り返しになりますが、これはserverタスクです。)

私の実験では、多くの場合、100〜1000行のチャンクが最適に近いことが示されています。 (これはたまたまあなたの発見と多少一致しますが、私が別のタイミングを見たので、それは偶然です。)

0
Rick James