ALTER TABLE ... コンパクト
読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はバックグラウンドでストレージ ノードのデータ圧縮を自動的にスケジュールします。圧縮中、ストレージ ノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のバージョンのデータのマージが含まれます。 ALTER TABLE ... COMPACT
ステートメントを使用すると、圧縮がバックグラウンドでトリガーされるまで待たずに、特定のテーブルの圧縮をすぐに開始できます。
このステートメントの実行は、既存の SQL ステートメントをブロックしたり、トランザクション、DDL、GC などの TiDB 機能に影響を与えたりしません。 SQL文で選択できるデータも変更されません。ただし、このステートメントを実行すると、一部の IO および CPU リソースが消費されるため、SQL 実行のレイテンシーが長くなる可能性があります。
テーブルのすべてのレプリカが圧縮されると、圧縮ステートメントが終了して返されます。実行プロセス中に、 KILL
ステートメントを実行することで圧縮を安全に中断できます。圧縮を中断しても、データの一貫性が損なわれたり、データが失われたりすることはなく、その後の手動またはバックグラウンドの圧縮にも影響しません。
このデータ圧縮ステートメントは現在、TiKV レプリカではなく、TiFlash レプリカでのみサポートされています。
あらすじ
- AlterTableCompactStmt
AlterTableCompactStmt ::=
'ALTER' 'TABLE' TableName 'COMPACT' 'TIFLASH' 'REPLICA'
例
テーブル内のコンパクトな TiFlash レプリカ
以下は、2 つの TiFlash レプリカを持つ 4 つのパーティションを持つemployees
のテーブルを例として取り上げています。
CREATE TABLE employees (
id INT NOT NULL,
hired DATE NOT NULL DEFAULT '1970-01-01',
store_id INT
)
PARTITION BY LIST (store_id) (
PARTITION pNorth VALUES IN (1, 2, 3, 4, 5),
PARTITION pEast VALUES IN (6, 7, 8, 9, 10),
PARTITION pWest VALUES IN (11, 12, 13, 14, 15),
PARTITION pCentral VALUES IN (16, 17, 18, 19, 20)
);
ALTER TABLE employees SET TIFLASH REPLICA 2;
次のステートメントを実行して、 employees
のテーブル内のすべてのパーティションの 2 つの TiFlash レプリカの圧縮をすぐに開始できます。
ALTER TABLE employees COMPACT TIFLASH REPLICA;
同時実行
ALTER TABLE ... COMPACT
ステートメントは、テーブル内のすべてのレプリカを同時に圧縮します。
オンライン ビジネスへの重大な影響を回避するために、各 TiFlash インスタンスは、デフォルトで一度に 1 つのテーブルのデータのみを圧縮します (バックグラウンドでトリガーされる圧縮を除く)。つまり、複数のテーブルで同時にALTER TABLE ... COMPACT
ステートメントを実行すると、それらの実行は同時に実行されるのではなく、同じ TiFlash インスタンスでキューに入れられます。
リソース使用量を増やしてテーブル レベルの同時実行性を高めるには、TiFlash 構成を変更しますmanual_compact_pool_size
。たとえば、 manual_compact_pool_size
を 2 に設定すると、2 つのテーブルのコンパクションを同時に処理できます。
MySQL の互換性
ALTER TABLE ... COMPACT
構文は TiDB 固有のもので、標準 SQL 構文の拡張です。同等の MySQL 構文はありませんが、MySQL クライアントまたは MySQL プロトコルに準拠するさまざまなデータベース ドライバーを使用して、このステートメントを実行できます。
TiDB Binlogと TiCDC の互換性
ALTER TABLE ... COMPACT
ステートメントは論理データの変更をもたらさないため、TiDB Binlogまたは TiCDC によってダウンストリームに複製されません。