web-dev-qa-db-ja.com

innodbフルテキストibdata1サイズ

私はmariadb10を実行していて、フルテキストインデックスを持つ大きなinnodbテーブルを持っています。 innodb_file_per_table = ONがあります

Ibdata1ファイルがテーブルファイルと同じ速度で大きくなることに気づきました。

Mysqldumpを使用して、ファイルを削除して再ロードし、UNDO表領域を分離してみました。どちらも違いはなかったので、これはある種のトランザクションのオーバーヘッドではないと思います。

Ibdata1ファイルには実際のフルテキストインデックスが保存されていますか、それともファイルの増加について別の説明がありますか?

1
nick robinson

まず、innodb_file_per_table=ONを使用すると、すべてのデータとインデックスページがテーブルの.ibdファイルに保存されます。

システムテーブルスペース(ibdata1)の増大は、大きな頭痛の種になる可能性があります。

私は以前の投稿でこれについて言及しました

あなたの場合、トランザクションのオーバーヘッドがあります。 mysqldumpが原因で、大きなトランザクションが発生します。どうして ?

-opt と呼ばれるデフォルトのオプションでは、 -extended-insert を含む多くのオプションが有効になっています。拡張挿入により、mysqldumpはバッチでINSERT INTO複数の行になります。行の各バッチは単一のトランザクションです。したがって、特にテーブルにTEXTまたはBLOBデータがある場合は、ibdata1が肥大化することが予想されます(フルテキストインデックスがあるためだと思います)。

これを回避する唯一の方法は、--skip-extended-insertを使用してmysqldumpを再度実行することです。これは3つの非常に厄介なことをします:

  1. 各行に対してINSERTを実行します
  2. はるかに大きなmysqldumpファイルを作成します
  3. リロードに1トン長くかかります

これにより、数百または数千ではなく1つの行を挿入するため、個々のINSERTトランザクションが数百または数千倍高速になります。残念ながら、INSERTの数が多いため、実行に数百または数千の時間がかかります。これは、ibdata1が肥大化するのを防ぐ1つの方法にすぎません。

別の方法として、テーブルからFULLTEXTインデックスを削除し、skip-extended-insertを使用してmysqldumpし、リロードしてから、FULLTEXTインデックスを追加し直すことができます。 FULLTEXTインデックスの追加はトランザクションではないため、これは役立つ可能性があります。

試してみる !!!

1
RolandoMySQLDBA