web-dev-qa-db-ja.com

OPTIMIZE TABLEの進行状況を示す進行状況インジケーターはありますか？

MySQL 5.1.4x（Windows）| Innodb

私は最近、mySQL DB（数十万行）からデータをパージし、使用する予定です

OPTIMIZE TABLE LOGTABLEFOO1,LOGTABLEFOO2,LOGTABLEFOO3;

データスペースのフットプリントを減らすために、空の空白がファイルシステムで使用されています。

私の懸念は、このコマンドを開始すると、どれくらいの時間がかかるのか、プロセスのどこにあるのかわからなくなることです。とにかくこの情報を特定できますか？私の知る限り、進行状況の指標はありません。

mysqlinnodbwindowsmysql-5.1
4
Mike B

MySQLには、OPTIMIZE TABLE;の進行状況を示すものはありません。

Windowsエクスプローラーを使用してOSにアクセスし、増大するtmpテーブルを探す必要がある場合があります。ヒント：一時テーブルは、#sql-9999.MYDおよび#sql-9999.MYIという名前の.frmファイルを持たないMyISAMテーブルです。これら2つのファイルは存在しますが、クエリは進行中と見なされます。どれだけの行があるかを知るには、行の数に平均行の長さを掛けた数を調べて、実行された割合または実行されなかった割合を推定する必要があります。

MariaDBには、以下の進捗状況測定機能があります ：

  • ALTER TABLE
  • ADD INDEX
  • DROP INDEX
  • LOAD DATA INFILE
  • CHECK TABLE
  • REPAIR TABLE
  • ANALYZE TABLE
  • OPTIMIZE TABLE

MySQLの操作の観点から以前に主題について説明しました

InnoDBのibdata1のサイズを削減しようとしている場合、テーブルを削除してもibdata1に大きなギャップが残るだけです。 InnoDBインフラストラクチャの完全なクリーンアップを実行する必要があります。

UPDATE 2012-12-21 19:30 EDT

このデータベースはinnodbを使用しているので、検索できる一時テーブルが増えていきますか？

あなたが走りたいとしましょう

OPTIMIZE TABLE mydb.mytable;

innodb_file_per_table およびこれを含む2つのシナリオを見てくださいOPTIMIZE TABLE

シナリオ＃1： innodb_file_per_table 無効

OPTIMIZE TABLEを実行すると、mydb.mytableのすべてのデータページとインデックスページがibdata1に連続して追加されます。これは、断片化の狂気にさらに追加するために以前占有されていたスペースを残します。

このシナリオでは、一時テーブルはInnoDBとして存在し、ibdata1で実体化します。したがって、視覚的に監視するものは何もありません。

シナリオ＃2： innodb_file_per_table 有効

InnoDBテーブルmydb.mytableごとに、

  • /var/lib/mysql/mydb/mytable.frm
  • /var/lib/mysql/mydb/mytable.ibd

.ibdファイルには、テーブルのデータページとインデックスページが含まれています。

OPTIMIZE TABLEを実行すると、mydb.mytableのすべてのデータとインデックスページが、Windowsエクスプローラーで確認できる外部.ibdファイルに書き込まれます。

警告

innodb_file_per_table を有効にしてOPTIMIZE TABLEを実行すると、以前にibdata1内で占有されていたスペースが再利用されることはありません。 InnoDB Cleanup を実行して、データとインデックスが決してibdata1に存在しないようにibdata1を再作成する必要があります。

結論

前述のように、MariaDBはOPTIMIZE TABLE;を監視できます

監視できるものが必要で、 innodb_file_per_table が有効になっている場合は、

OPTIMIZE TABLE LOGTABLEFOO1,LOGTABLEFOO2,LOGTABLEFOO3;

次の機械的同等物を使用して：

CREATE TABLE LOGTABLEFOO1_NEW LIKE LOGTABLEFOO1;
INSERT INTO LOGTABLEFOO1_NEW SELECT * FROM LOGTABLEFOO1;
ALTER TABLE LOGTABLEFOO1 RENAME LOGTABLEFOO1_OLD;
ALTER TABLE LOGTABLEFOO1_NEW RENAME LOGTABLEFOO1;
DROP TABLE LOGTABLEFOO1_OLD;
ANALYZE TABLE LOGTABLEFOO1;

CREATE TABLE LOGTABLEFOO2_NEW LIKE LOGTABLEFOO2;
INSERT INTO LOGTABLEFOO2_NEW SELECT * FROM LOGTABLEFOO2;
ALTER TABLE LOGTABLEFOO2 RENAME LOGTABLEFOO2_OLD;
ALTER TABLE LOGTABLEFOO2_NEW RENAME LOGTABLEFOO2;
DROP TABLE LOGTABLEFOO2_OLD;
ANALYZE TABLE LOGTABLEFOO2;

CREATE TABLE LOGTABLEFOO3_NEW LIKE LOGTABLEFOO3;
INSERT INTO LOGTABLEFOO3_NEW SELECT * FROM LOGTABLEFOO3;
ALTER TABLE LOGTABLEFOO3 RENAME LOGTABLEFOO3_OLD;
ALTER TABLE LOGTABLEFOO3_NEW RENAME LOGTABLEFOO3;
DROP TABLE LOGTABLEFOO3_OLD;
ANALYZE TABLE LOGTABLEFOO3;

OPTIMIZE TABLE はALTER TABLE ... ENGINE=InnoDB;の後に ANALYZE TABLE が続くことを覚えておいてください。

これらの手順で、一時テーブルが何であるかを事前に知ることができます

  • LOGTABLEFOO1_NEW.ibd
  • LOGTABLEFOO2_NEW.ibd
  • LOGTABLEFOO3_NEW.ibd

各ファイルの存在とサイズが消えるまで監視するだけです。

10
RolandoMySQLDBA

ファイルシステムにアクセスできる場合は、もっと簡単な方法があります。

MySQLは.TMDファイルを生成します。ファイルのサイズが大きくなるのを見ることができます。それが完了すると、多かれ少なかれ既存のMYDのサイズに達するはずです。

たとえば、datadirにcdし、単にwatch "ls -lah|grep table_name"は、このようなものを返します（Linuxの場合）。私の場合、進行状況は427 MBから287 MBです（大体）。

-rw-rw----.  1 mysql mysql 427M Feb 19 23:45 ticket_change.MYD
-rw-rw----.  1 mysql mysql 541M Feb 20 01:10 ticket_change.MYI
-rw-rw----.  1 mysql mysql 287M Feb 20 01:45 ticket_change.TMD
1
Pierre-Olivier Benoit

Percona Toolkitの pt-online-schema-change がこれを行います。

変化する mydb.LOGTABLEFOO1からInnoDBまで、効果的にOPTIMIZE TABLEそれはすでにInnoDBテーブルなので、非ブロッキング方式で

pt-online-schema-change --alter "ENGINE=InnoDB" D=mydb,t=LOGTABLEFOO1
0
cornernote