私はmariadb10を実行していて、フルテキストインデックスを持つ大きなinnodbテーブルを持っています。 innodb_file_per_table = ONがあります
Ibdata1ファイルがテーブルファイルと同じ速度で大きくなることに気づきました。
Mysqldumpを使用して、ファイルを削除して再ロードし、UNDO表領域を分離してみました。どちらも違いはなかったので、これはある種のトランザクションのオーバーヘッドではないと思います。
Ibdata1ファイルには実際のフルテキストインデックスが保存されていますか、それともファイルの増加について別の説明がありますか?
まず、innodb_file_per_table=ON
を使用すると、すべてのデータとインデックスページがテーブルの.ibd
ファイルに保存されます。
システムテーブルスペース(ibdata1)の増大は、大きな頭痛の種になる可能性があります。
私は以前の投稿でこれについて言及しました
Apr 23, 2013
: innodb_file_per_tableが設定されている場合でもInnodb ibdata1ファイルを5倍に増やすにはどうすればよいですか?Mar 31, 2014
: 1つのクエリの後にmysqlディレクトリが246Gに増加しますが、テーブルがいっぱいであるため失敗しましたJun 16, 2014
: テーブルで失敗するMySQLインデックスの作成がいっぱいですあなたの場合、トランザクションのオーバーヘッドがあります。 mysqldumpが原因で、大きなトランザクションが発生します。どうして ?
-opt と呼ばれるデフォルトのオプションでは、 -extended-insert を含む多くのオプションが有効になっています。拡張挿入により、mysqldumpはバッチでINSERT INTO
複数の行になります。行の各バッチは単一のトランザクションです。したがって、特にテーブルにTEXTまたはBLOBデータがある場合は、ibdata1が肥大化することが予想されます(フルテキストインデックスがあるためだと思います)。
これを回避する唯一の方法は、--skip-extended-insert
を使用してmysqldumpを再度実行することです。これは3つの非常に厄介なことをします:
これにより、数百または数千ではなく1つの行を挿入するため、個々のINSERTトランザクションが数百または数千倍高速になります。残念ながら、INSERTの数が多いため、実行に数百または数千の時間がかかります。これは、ibdata1が肥大化するのを防ぐ1つの方法にすぎません。
別の方法として、テーブルからFULLTEXTインデックスを削除し、skip-extended-insert
を使用してmysqldumpし、リロードしてから、FULLTEXTインデックスを追加し直すことができます。 FULLTEXTインデックスの追加はトランザクションではないため、これは役立つ可能性があります。
試してみる !!!