スキーマキャッシュ
マルチテナント シナリオによっては、データベースとテーブルが数十万、あるいは数百万ある場合があります。これらすべてのデータベースとテーブルのスキーマ情報をメモリにロードすると、大量のメモリが消費されるだけでなく、アクセス パフォーマンスも低下します。この問題に対処するために、TiDB では LRU (Least Recently Used) に似たスキーマ キャッシュ メカニズムが導入されています。メモリにキャッシュされるのは、最近アクセスされたデータベースとテーブルのスキーマ情報のみです。
スキーマキャッシュを構成する
システム変数tidb_schema_cache_sizeを構成することで、スキーマ キャッシュ機能を有効にすることができます。
ベストプラクティス
- データベースとテーブルの数が多いシナリオ (たとえば、100,000 を超えるデータベースとテーブル) の場合、またはデータベースとテーブルの数がシステム パフォーマンスに影響を与えるほど大きい場合は、スキーマ キャッシュ機能を有効にすることをお勧めします。
- TiDB ダッシュボードのスキーマ ロードセクションのサブパネルInfoschema v2 Cache Operation を観察することで、スキーマ キャッシュのヒット率を監視できます。ヒット率が低い場合は、値を
tidb_schema_cache_sizeに増やすことができます。 - TiDB ダッシュボードのスキーマ ロードセクションのサブパネルInfoschema v2 キャッシュ サイズを観察することで、使用されているスキーマ キャッシュの現在のサイズを監視できます。
- TiDB の起動時間を短縮するには、
performance.force-init-stats無効にすることをお勧めします。 - 多数のテーブル (たとえば、100,000 を超えるテーブル) を作成する必要がある場合は、
split-tableパラメータをfalseに設定してリージョンの数を減らし、TiKV のメモリ使用量を減らすことをお勧めします。
既知の制限
多数のデータベースとテーブルがあるシナリオでは、次の既知の問題が存在します。
テーブルへのアクセスが不規則な場合 (たとえば、1 セットのテーブルが time1 にアクセスされ、別のセットが time2 にアクセスされる場合など)、
tidb_schema_cache_sizeの値が小さいと、スキーマ情報が頻繁に削除およびキャッシュされ、パフォーマンスの変動が発生する可能性があります。この機能は、頻繁にアクセスされるデータベースとテーブルが比較的固定されているシナリオに適しています。統計情報はタイムリーに収集されない可能性があります。
一部のメタデータ情報へのアクセスが遅くなる可能性があります。
スキーマ キャッシュのオン/オフを切り替えるには、待機期間が必要です。
次のような、すべてのメタデータ情報を列挙する操作は遅くなる可能性があります。
SHOW FULL TABLESFLASHBACKALTER TABLE ... SET TIFLASH MODE ...
属性が
AUTO_INCREMENTまたはAUTO_RANDOMテーブルを使用する場合、スキーマ キャッシュ サイズが小さいと、これらのテーブルのメタデータがキャッシュに頻繁に入出力される可能性があります。その結果、割り当てられた ID 範囲が完全に使用される前に無効になり、ID ジャンプが発生する可能性があります。書き込みが集中するシナリオでは、ID 範囲が使い果たされる可能性もあります。異常な ID 割り当て動作を最小限に抑え、システムの安定性を向上させるには、次の対策を講じることをお勧めします。- 監視パネルでスキーマ キャッシュのヒット率とサイズをビュー、キャッシュ設定が適切かどうかを評価します。頻繁な削除を減らすには、スキーマ キャッシュ サイズを適切に増やします。
- ID ジャンプを防ぐには
AUTO_ID_CACHEから1に設定します。 - ID 範囲が小さくなりすぎないように、シャード ビットおよび予約ビットを
AUTO_RANDOMに適切に構成します。