スキーマキャッシュ
マルチテナントのシナリオによっては、数十万、あるいは数百万ものデータベースとテーブルが存在する場合があります。これらすべてのデータベースとテーブルのスキーマ情報をメモリにロードすると、大量のメモリを消費するだけでなく、アクセスパフォーマンスも低下します。この問題に対処するため、TiDBはLRU（Least Recently Used：最長時間未使用）に似たスキーマキャッシュメカニズムを導入しています。メモリにキャッシュされるのは、最も最近アクセスされたデータベースとテーブルのスキーマ情報のみです。
注記：
現在、この機能はTiDB CloudスターターおよびTiDB Cloudエッセンシャルクラスターでは利用できません。
スキーマキャッシュを構成する
システム変数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 つのクラスター内のテーブル数は 300 万を超えることはできません。
1 つのクラスター内のテーブル数が 300,000 を超える場合は、値
tidb_schema_cache_sizeを0に設定しないでください。TiDB でメモリ不足 (OOM) が発生する可能性があります。外部キーを使用すると、クラスター内の DDL 操作の実行時間が長くなる可能性があります。
テーブルへのアクセスが不規則な場合（例えば、あるテーブルセットが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に適切に構成します。