業務でコールドデータへの継続的かつ高負荷なアクセスがある場合、IA は推奨されません。テーブルを Standard ストレージに戻してください。 システムの安定性を確保するため、将来の技術リリースではコールドデータアクセスに対するハードスロットリングが追加される予定です。現時点では、上記の制約を順守する必要があります。
単一 SQL によるコールドデータアクセス量は、Cloud Console → Monitoring → Diagnosis → Slow Query → Coprocessor の IA Remote Read Segment Size パネルで監視できます。クラスター全体の IA キャッシュ動作を監視するには、階層型ストレージの可観測性 で説明されている IA Cache Performance パネルを使用してください。
階層型ストレージは、最近アクセスされたコールドデータへの繰り返しアクセスを高速化するために、ローカル IA データキャッシュ（IaManager により管理）を維持します。ただし、次の重要な点を理解しておく必要があります。
キャッシュ容量は調整可能ですが、キャッシュ動作は引き続きシステム管理です: Cloud Console で IA キャッシュレベルを選択し、ローカルディスク上にキャッシュする IA データ量を制御できます。ただし、エビクションポリシーは引き続きシステムによって管理されます。どのデータをキャッシュに残すかを指定できず、キャッシュレベルは個別の論理インスタンス、テーブル、またはパーティションではなく、基盤となる TiKV 物理クラスターに適用されます。キャッシュヒット率は実際のアクセスパターンに依存します。アクセスが集中していれば 95% を超えることがありますが、アクセスが分散している場合は 95% を下回ることがあります。
IA クエリの応答時間は一定ではありません: クエリがローカルキャッシュにヒットした場合、性能は Standard テーブルに近くなります。しかし、データをリモートオブジェクトストレージからロードする必要がある場合（キャッシュミス）、各リモートリクエストで約 500ms~2s のレイテンシーが追加されます。1 回の SQL 実行で複数回のリモートロードが発生することがあり、その結果レイテンシーが累積します。そのため、IA テーブルのクエリ応答時間は Standard テーブルほど予測可能ではありません。業務側ではこの点を考慮して計画する必要があります。
推奨: パーティションテーブルを使用してコールドデータの範囲を正確に制御する: パーティションテーブルを使用し、低頻度アクセスであることが確認された履歴パーティションのみを IA に設定し、アクティブなパーティションは Standard のままにしてください。これにより、キャッシュの不確実性を明確に定義されたデータ範囲に限定でき、テーブル全体のクエリ性能をキャッシュミスリスクにさらさずに済みます。
キャッシュ領域を増やすことはコスト増加を意味します: より高いキャッシュレベルでは、より多くの IA データがローカルディスクに保持されるため、より多くのローカルディスクおよび TiKV リソースを消費します。TiDB Cloud Premium では、より高いキャッシュレベルにより課金対象の IA ストレージ量が増加します。TiDB Cloud BYOC では、追加リソースはお客様自身のクラウドアカウント内にプロビジョニングされ、クラウドプロバイダーから課金され、プロビジョニング完了までに時間がかかります。業務要件に応じて、コールドリード性能とコストのバランスを取ってください。
要するに: IA ストレージは、ストレージコストを削減する代わりに、クエリ性能の予測可能性を低下させます。これは設計上避けられないトレードオフです。どのデータをコールドデータとするかを正確に定義し、その影響をそのデータに限定するために、パーティションテーブルを使用してください。業務で予測可能なクエリ応答時間が必要な場合は、レイテンシーに敏感なデータを Standard ストレージに保持してください。