MySQL 5.7.17 EnterpriseエディションをRHELで使用し、構成innodb_file_per_table = ONを使用しています。
だから今ここに私は2つの質問があります:
テーブルごとのibdファイルの代わりに、定期的に更新されるデータディレクトリでibdata1、ib_logfile1、ib_logfile0を確認できます。ただし、これらのファイルのサイズは大きくありませんが、全体として15〜20 GBのスペースを消費します。それで、テーブルごとにibdファイルを "ON"にする代わりに、これらのファイルはまだ存在しますか、またはそれらが含まれている場合、定期的に更新されますか?
私は393 GBをデータディレクトリに割り当てました。 1つのデータベースフォルダーだけで293 GBを使用しています。サイズが84 GB〜100 GBのtable_name.ibdファイルがあります。メモリが浪費されているかどうかを確認する方法はありますか?そしてそれが無駄になっている場合、どうすればそれを取り戻すことができますか?
大きなテーブルに対してこのコマンドを実行する場合、必要なスペースはtable_size * 2であるため、optimizeコマンドを使用する前により多くのスペースが必要になるため、一部の小さなテーブルに対してのみ最適化テーブルを実行しました(これは役に立ちました)。
テーブルサイズもチェックしました。テーブルのサイズとそれぞれのテーブルのibdファイルのサイズは、2〜3 GBの違いがあります。
誰かが私を助けてくれますか、ここで何ができますか?
MySQLデータディレクトリを新しいパスにポイントする必要がありますか?可能であれば、どうすればよいですか?
降順のファイルサイズ(GB):93 33 19 17 16 14 13 11 11 9.2
上位のテーブルスペースファイルサイズを投稿したので、質問への回答を以下に示します。
innodb_file_per_table
の値に関係なく、ibdataおよびib_logfileファイルはそこにあります。 innodb_data_file_path
の構成方法によっては、複数のibdataファイルが存在する場合があります。 ib_logfileは、innodb_log_files_in_group
に使用する値に応じて複数になる場合もあります。ログファイルの適切なサイズを計算するには、 Innodbログファイルの適切なサイズを計算する方法 を参照してくださいIb_logfilesがGBの場合、本当に必要なサイズを再計算し(上記のリンクを参照)、それに応じてサイズを設定するのが最善です。 ibdata *ファイルのサイズ変更は困難です(私が知っている唯一の方法は、DB全体をmysqldumpして、新しいインストールに再インポートすることです)。
次のクエリを使用して、圧縮可能な空きテーブルスペースを計算できます。
SELECT table_name、(data_free)/ power(1024,2)free_space_mb FROM information_schema.tables WHERE table_schema = '[yourdb]' ORDER BY free_space_mb DESC;
GB相当の空き領域があるテーブルを見つけた場合、そのようなテーブルでOPTIMIZE
を実行すると、ディスク上のテーブルスペースのサイズが小さくなります。
データファイルを取得したい使用可能なディスク/ボリュームが大きい場合は、以下をガイドとして使用してください。
/etc/my.cnf
を編集し、mysqlファイルをコピーした新しい場所にdatadir
を設定しますthatsaruはほとんどの問題をカバーしました。
ディスクの空き領域を最大のテーブルのサイズよりも小さくするのは賢明ではありません。そうすれば、どのテーブルでもALTER
またはOPTIMIZE
できるようになります。 (あなたは明らかにその安全なポイントをはるかに超えています。)
ibdata1
は、innodb_file_per_table = ON
を使用しても引き続き変更されます。そこに格納されているデータやインデックス以外にもさまざまなものが存在します。ファイルのサイズはときどき大きくなることがありますが、縮小されることはありません。それを縮小する唯一の方法は、完全なダンプとリロードを行うことです。楽しくない。
InnoDBにはiblog*
ファイル(通常は2つ)が必要です。それらの大きさについては、いくつかの緩いガイドラインがあります。明らかに、サイズを大きくする余地がありません。 MySQLの本当に新しいバージョンを使用していない限り、それらのサイズを縮小するのは面倒です。しかし、それは可能ですので、これは絶望的な措置かもしれません。欠点は、パフォーマンスの低下(おそらく小さい)です。
テーブルの「空き」スペースは非常に不正確です。 SHOW TABLE STATUS
またはinformation_schema.TABLES
から見つけることができます。 PARTITIONed
テーブルには、パーティション化されていないテーブルよりも多くの「空き」スペースがあります。
最小から始めてOPTIMIZE TABLE
を使用していますか?そして今、あなたは次のものを行うことができませんか?さて、あなたは運が悪いです。いくつかのテーブルを削除します。より大きなディスクを取得します(データを移行します)。または他の痛みを伴う治療法。
OTOH、次に大きいテーブルのスキーマを見てみましょう。多分それはDROPped
になることができるいくつかのインデックスを持っています。 BIGINT
で十分な場合(8バイト-> 4バイト)、INT
を使用する可能性があります。このような十分なクリーンアップが見つかれば、おそらくALTER TABLE t MODIFY COLUMN ..., DROP INDEX ...;
は正常に実行されます。
ALTER
とOPTIMIZE
はテーブルをコピーし、インデックスを再構築します。そうすることで、ディスクのフットプリントがたまたま大きくなる可能性があります。これらにより、テーブルが大きくなる傾向があります。現在の最大値よりPRIMARY KEY
少ない挿入。アップデート;削除します。