テーブルメンテナンス

選択したテーブルを、サーバにある操作で分析、チェック、最適化、修復します。

場所：ワークスペース › ツール › テーブルメンテナンス

ワークスペースのサイドバーから「テーブルメンテナンス」を開きます。左のツリーでテーブルを選び（データベースのチェックボックスでそのテーブルをすべて選べます。1つずつチェックしてもかまいません）、上で操作（「ANALYZE」、「CHECK」、「CHECKSUM」、「OPTIMIZE」、「REPAIR」）を選んで「実行」をクリックします。ボタンの横に、選択中のテーブル数が表示されます。

結果は下に表示され、サーバが各テーブルについて返すメッセージごとに1行になります：警告はオレンジ、エラーは赤で強調されます。InnoDBでは、OPTIMIZEは注記で答えます：代わりにテーブルを再構築して分析します。CHECKSUMはテーブルごとに1つの数値を返し、2台のサーバで同じ数値なら行も同じです。REPAIRは、ストレージエンジンが自分で修復できるテーブル（MyISAM、Aria、ARCHIVE、CSV）でしか実行されません。実行する前に、修飾子の下の行に、選択したテーブルのうち何個がスキップされるかが表示され、それぞれに理由を述べる行が付きます。InnoDBでは、その行はテーブルを再構築するOPTIMIZEを勧めます。Macでは列の見出しをクリックすると結果を並べ替えられ、「結果を消去」でリストが空になります。操作の実行中は、「実行」の横に進行状況バーと「キャンセル」が表示されます。テーブルは1つずつ処理されるので、キャンセルすると次のテーブルの前で止まります。

ツリーの見出しには、SQLエディタと同じ「名前でフィルタ」があります：データベース名やテーブル名の一部を入力すると、リストが絞り込まれます。各データベースは最初に展開したときにテーブルを読み込むので、まだ展開していないデータベースがある状態でフィルタすると、フッターに足りない数が表示され、読み込むよう提案されます。「すべてを選択」は、サーバ自身のシステムデータベースを除くサーバ上のすべてのデータベースを対象にします（システムデータベースは手でチェックできます）。数秒かかることがあります。サーバがあるテーブルでの操作を拒否した場合、そのテーブルにはサーバのメッセージを載せたエラーの行が付きます。

SQL Server

操作は3つです：ANALYZE（UPDATE STATISTICS）、CHECK（DBCC CHECKTABLE）、OPTIMIZE（ALTER INDEX ALL … REBUILD）。REPAIRはありません（データベースをシングルユーザモードにする必要があり、データを失うことがあります）。CHECKSUMもありません。OPTIMIZEは再構築のあいだテーブルをロックします：オンラインでの再構築はEnterpriseエディションにしかなく、空間インデックスでは使えません。

PostgreSQL

操作は2つです：ANALYZEと、VACUUMのあとにREINDEX TABLE CONCURRENTLYを実行するOPTIMIZEで、こちらはテーブルごとに2行を返します。どちらもテーブルを止めません。CHECKはなく（コアに相当するものがありません）、REPAIR、CHECKSUM、修飾子もありません。システムにディスク容量を返す唯一のVACUUM FULLは、書き直すあいだテーブル全体をロックするため、意図的に外しています。12より古いサーバでは、OPTIMIZEはVACUUMで止まり、インデックスの行にその理由が表示されます。

ClickHouse

ClickHouseでは操作は2つです：テーブルのパートごとに1行を返すCHECKと、パートをマージするOPTIMIZE。ANALYZE、REPAIR、CHECKSUMはエンジンになく、表示されません。テーブルを1つだけチェックすると「パーティション」が表示され、テーブル全体ではなく1つのパーティションを最適化できます。

Oracle

Oracleでは操作は1つだけです：DBMS_STATS.GATHER_TABLE_STATSでテーブルとそのインデックスの統計情報を収集するANALYZE。結果の行には、統計情報が数える行数と収集した日時が表示されます。CHECK、REPAIR、CHECKSUM、OPTIMIZEはありません：Oracleにはテーブル単位のそうした操作がなく、提示されません。別のスキーマのテーブルに対する権限がなければ、行には統計情報を収集できなかったと表示され、その下にサーバのメッセージが付きます。「キャンセル」は処理中のテーブルも中断します：サーバがDBMS_STATSを途中で打ち切り（ORA-01013）、そのテーブルにはリストの行が付きません。

TiDB

TiDBでは操作は2つです：ANALYZEと、ADMIN CHECK TABLE（インデックスと行を照合します）をテーブルごとに実行するCHECK。何も見つからなければ、行にはテーブルに問題がないと表示されます。何か見つかれば、インデックスの名前を挙げたサーバのメッセージがそこに入ります。REPAIR、CHECKSUM、OPTIMIZEはありません：TiDBにはなく（ストレージが自分で圧縮します）、提示されません。

読み出し専用の環境タグがあると、このツールは提示されません。書き込みを確認する環境タグでは、ANALYZE、OPTIMIZE、REPAIRはバッチごとに一度確認を求めます。読み取りだけのCHECKとCHECKSUMは確認を求めません。

キーワード： ANALYZE、CHECK、OPTIMIZE、REPAIR、メンテナンス、CHECKSUM

操作の修飾子

操作の動作を変える追加のオプション。

場所：テーブルメンテナンス › 修飾子のグリッド

操作の下には修飾子のグリッドがあります：「LOCAL（binlogなし）」、FOR UPGRADE、QUICK、FAST、MEDIUM、EXTENDED、CHANGED、USE_FRM。各操作は受け付けるものだけを有効にし、操作を変えると選択は消去されます。たとえば、QUICKは不正なリンクを探して行を走査しないことでCHECKを速くし、FOR UPGRADEは現在のサーバのバージョンとの互換性をチェックし、LOCALはANALYZE、OPTIMIZE、REPAIRをバイナリログに残さないので、レプリカはそれを繰り返しません。CHECKSUMでは、QUICKはテーブルが常時保持しているチェックサムだけを報告し、ほとんどのテーブルは保持していません。USE_FRMはMyISAMテーブルのインデックスを定義から再構築します。最後の手段です。

グリッドには、エンジンにある修飾子だけが表示されます。SQL Serverでは、CHECKはPHYSICAL_ONLY（構造だけで、より速い）とEXTENDED_LOGICAL_CHECKSを受け付けます。PostgreSQLには修飾子がなく、このセクションは描画されません。

ClickHouse

ClickHouseでは修飾子はOPTIMIZE用のFINALだけで、初期状態はオフです：テーブル（またはパーティション）を1つのパートにまとめることを強制し、チェックすると、数時間かかり2倍のディスク容量が必要になりうるという警告が表示されます。

Oracle

Oracleには修飾子がなく、このセクションは描画されません。

TiDB

TiDBには修飾子がなく、このセクションは描画されません。

キーワード： QUICK、EXTENDED、FOR UPGRADE、LOCAL、修飾子