mcp-developer-analysis

Materialize 開発者分析

MCP 開発者エンドポイントを通じて Materialize 環境を分析し、健全性ステータス、パフォーマンスの調査結果、最適化の推奨事項を含む構造化レポートを作成します。Materialize v26.24 以降を前提としています。

開発者エンドポイントでは、読み取り専用ツールを 2 つ利用できます。

• query_system_catalog — システムカタログテーブル（mz_*、pg_catalog、information_schema）に限定された SELECT／SHOW／EXPLAIN を実行します。クラスター引数は受け取りません。渡しても拒否されず、黙って無視されます。auto_route_catalog_queries が有効な間（デフォルト）は、カタログの読み取りはカタログサーバークラスター（mz_catalog_server）に自動ルーティングされます。ルーターがそこで処理できないクエリ（特に、すべての mz_introspection リレーション）は、セッションのデフォルトクラスター（ロールの cluster デフォルトが設定されていればその値、そうでなければシステムのデフォルトである quickstart。オペレーターが変更している場合を除く）で実行されます。ほとんどのカタログ参照にはこちらを使用してください。
• query（Materialize v26.30 で追加）— 必須の cluster 引数で指定したクラスター上で、ロールがアクセスできるあらゆるオブジェクトに対して SELECT／SHOW／EXPLAIN を実行します（v26.33 以降は、任意の cluster_replica も指定できます）。EXPLAIN ANALYZE（MV／インデックスのクラスター上で実行する必要があります）と、ユーザーデータを直接読み取る場合に必須です。オペレーターが enable_mcp_developer_query_tool を無効にしている場合、表示されないことがあります。

MCP クライアントを materialize-developer に接続する

ユーザーが MCP クライアント（Claude Code、Cursor、VS Code、Zed、Continue、Windsurf、Claude Desktop）から materialize-developer サーバーに接続するための設定、接続、またはセットアップ方法を尋ねている場合（接続で使用するユーザーやロールの指定方法、または ID の切り替え方法を含む）は、mcp-client-connect.md を参照してください。Emulator、Materialize Cloud、セルフマネージドデプロイメントに対応し、クライアントごとのコード例、認証パターン、検証手順を説明しています。

この SKILL.md の以降の部分では、接続した後に環境を分析する方法を説明します。

テーブルと列の確認

列名を推測してはいけません。 システムカタログのリレーションには、テーブル、ビュー、マテリアライズドビュー、ソースが混在しているため、単一の SHOW TABLES や SHOW VIEWS ですべてを一覧表示することはできません。SHOW OBJECTS FROM <schema> を使用してください。mz_internal のオントロジービューはカタログについて説明するものです。これらを使用して、正しいテーブル、列、結合経路、ID 型を確認してください。

テーブル	説明
mz_internal.mz_ontology_entity_types	存在するカタログエンティティと、それらが対応する mz_* テーブル。
mz_internal.mz_ontology_link_types	エンティティ間の関係（外部キー、メトリクスなど）。
mz_internal.mz_ontology_properties	各エンティティの列名、型、説明。
mz_internal.mz_ontology_semantic_types	型付き ID ドメイン（CatalogItemId、ReplicaId など）。

クエリの例：

-- Find the right table for an entity
SELECT name, relation, description
FROM mz_internal.mz_ontology_entity_types
WHERE name LIKE '%source%'

-- Find join paths between entities
SELECT name, source_entity, target_entity, properties, description
FROM mz_internal.mz_ontology_link_types
WHERE source_entity = 'source' OR target_entity = 'source'

-- Find columns for a table
SELECT column_name, semantic_type, description
FROM mz_internal.mz_ontology_properties
WHERE entity_type = 'source_status'

クエリを実行する前に、SHOW COLUMNS FROM <schema>.<table> で列名を確認してください。

重要なルール

サーバー自身の initialize 指示には、カタログに関する注意事項が記載されています。たとえば、last_status_change_at などの列名、mz_cluster_replica_utilization のレプリカとクラスター間の JOIN、オントロジービュー、そして v26.40 以降の mz_introspection のルーティングと ID 型です。ほとんどのクライアントはこれらを転送します。転送されない場合は、代わりに SHOW COLUMNS を使用してください。

mz_introspection リレーションには query ツールが必要です

mz_dataflow_arrangement_sizes を含むすべての mz_introspection リレーションはクラスターのスコープに属します。また、query_system_catalog ではクラスターを指定できないため、このツールを使った読み取りはセッションのデフォルトクラスターで実行されます。そのクラスターにレプリカがちょうど 1 つあれば、その数値が返されるか、エラーなしで空の結果が返されます。レプリカが複数ある場合、読み取りは log source reads must target a replica というエラーで失敗し、レプリカがない場合は has no replicas available to service request というエラーで失敗します。cluster 引数を指定して query から読み取り、レプリカが複数あるクラスターでは cluster_replica（v26.33 以降）も指定してください（課金対象外のレプリカも数に含まれます）。これが最初のエラーに対する指定方法です。2 つ目のエラーを解決する方法はありません。 v26.40 より前のサーバーでは、initialize の指示で mz_dataflow_arrangement_sizes をクエリしないよう案内されます。このルールは query ツールより前のものなので、ここではこの案内が優先されます。クエリ、カタログへの結合経路、および注意事項については、references/queries.md の「Arrangement Sizes」を参照してください。query ツールがない場合は、以下の「Memory and Resource Consumption」に記載されているリレーションを使用してください。

ワークフローの概要

1. 接続 — MCP Developer ツールが利用可能であることを確認します
2. 検出 — オントロジーとカタログクエリを使って、デプロイ済みのすべてのオブジェクトを一覧化します
3. 分析 — パフォーマンス指標（鮮度、ハイドレーション、メモリ、使用率）を評価します
4. レポート — 調査結果と推奨事項をまとめた構造化 Markdown レポートを作成します

ステップ 1：MCP 接続を確認する

query_system_catalog ツールにアクセスできることを確認します。簡単なテストを実行します。

query_system_catalog: SELECT mz_version() FROM mz_catalog.mz_databases LIMIT 1

query_system_catalog はシステムカタログテーブルを参照しない SELECT を拒否するため、単独の SELECT mz_version() は Query must reference at least one system catalog table というエラーになります。このエラーは接続に問題があるように見えます。

クライアントが公開しているツールに query ツールが含まれているか確認します。このツールがあれば、名前付きクラスター上で EXPLAIN ANALYZE やユーザーオブジェクトに対するクエリも実行できます。ツールがない場合（オペレーターによって無効にされている場合、または v26.30 より前のビルドの場合）は、query_system_catalog で実行可能なすべての処理を行ってください。

query_system_catalog が失敗した場合は、次の点を確認してください。

• MCP サーバーがクライアントの MCP 設定に登録されていること（ファイルとキーはクライアントによって異なります。mcp-client-connect.md を参照してください）
• 環境で enable_mcp_developer フィーチャーフラグが有効になっていること
• 認証情報が有効であること

クエリの実行

どちらのツールも、呼び出しごとに読み取り専用のステートメントを1つだけ受け付けます。SET は使用できず、末尾のセミコロンも付けないでください（1つなら許容されますが、2つのステートメントは拒否されます）。

結果は、列名のない行の配列として返されます。すべての AS エイリアスは破棄されるため、列は位置で対応付け、SELECT リストは短く保ち、読み取りたい順に並べてください。数値は文字列として、ブール値は JSON の true／false として、NULL は null として返されます。timestamp と timestamptz の値は、ミリ秒単位のエポックからの経過時間を表す文字列（1787687415336.000）として返されるため、読みやすい時刻が必要な場合は text にキャストしてください。オブジェクトがセッションのデータベース（SHOW database）にない場合は、オブジェクト名をデータベース名で修飾してください。そうしないと、ステートメントは unknown schema で失敗します。レスポンスには既定で1 MBの上限があり、リクエストには既定で60秒のタイムアウトが設定されています。どちらもオペレーターが変更でき、上限に達するとエラーになります。LIMIT を指定すると、カタログの列挙が上限内に収まります。また、単一のインデックス付きリレーションを単純に読み取る場合に限り、処理量を減らせます。結合では処理量は減りません。タイムアウトすると呼び出しは解放されますが、クエリが実行されたままになることがあります。そのため、タイムアウトしたステートメントをそのまま再試行しないでください。

query_system_catalog は FROM 句のテーブル参照をたどって許可リストを確認するため、FROM 句がないステートメントはまったく確認されません。SHOW TABLES、SHOW COLUMNS、SHOW CREATE 形式のステートメント、およびオブジェクトレベルの EXPLAIN ANALYZE はここで許可され、ユーザーオブジェクトを指定できます（後者が空の結果を返す理由については、「ワーカーの偏り」を参照してください）。query を利用できない場合の代替手段として使用してください。ユーザーオブジェクトには query を使用します。

システムスキーマを除外するときは、必ず次のものを除外してください：mz_catalog、mz_internal、pg_catalog、information_schema、mz_introspection。SHOW SCHEMAS には、リレーションを含まない mz_catalog_unstable と mz_unsafe も表示されます。

Step 2: 検出 — 環境のインベントリ作成

検出クエリを実行して、デプロイされている内容を把握します。クエリ一式については、references/queries.md を参照してください。検出フェーズでは、次の項目を確認します。

環境の概要

• Materialize のバージョン
• クラスターとレプリカ — 名前、managed、レプリカ数、サイズ。mz_clusters を起点にレプリカを LEFT JOIN してください。そうしないと、レプリカのないクラスターがインベントリから除外されます。管理対象外のクラスターでは、size と replication_factor が NULL になります。課金対象外のサポート用レプリカは mz_internal.mz_internal_cluster_replicas に一覧され、ほかのレプリカと同様に数に含めます。
• 使用中のスキーマ

デプロイ済みオブジェクトのインベントリ

• ソース：タイプ（Kafka、Postgres、MySQL、Webhook など）、クラスターの割り当て、ステータス。mz_sources には、すべてのサブソースと progress コレクションの行も含まれるため、ソース数を報告する前に type NOT IN ('subsource', 'progress') で絞り込んでください。
• マテリアライズドビュー：クラスターの割り当て、インデックス、依存関係
• ビュー：（非マテリアライズド）と使用パターン
• シンク：タイプ、出力先、クラスターの割り当て
• インデックス：対象、クラスターの割り当て
• 接続：設定済みの外部システム接続

オブジェクト定義

references/queries.md を使用して、マテリアライズドビュー、ビュー、インデックス、ソースの SQL 定義を取得します。これは最適化分析に不可欠です。SQL 定義から、どのように処理されているかが分かります。

• 結合パターンと結合順序
• フィルタ述語（またはその欠如。時間フィルタの欠如はよくある問題です）
• 集約方法
• 共有できるロジックをマテリアライズドビューで重複していないか

Step 3: 分析 — パフォーマンスとリソースのメトリクス

フレッシュネス（遅延分析）

オブジェクトごとの遅延を確認するには、mz_internal.mz_materialization_lag をクエリします。local_lag 列と global_lag 列は通常の interval 型なので、そのまま比較やソートができます。また、slowest_global_input_id には、オブジェクトの処理を遅らせている入力が示されます。どちらの遅延も壁時計ではなく入力のフロンティアを基準に測定されます。したがって、ソースが一時停止しているパイプラインでは、古さが際限なく増していても遅延はゼロと表示されます。そのため、mz_frontiers.write_frontier も now() と比較してください（Write Frontiers クエリ）。

write_frontier はこのリレーションにはありません。mz_internal.mz_frontiers に mz_timestamp 型として格納されています。読みやすい時刻にするには timestamptz にキャストし、生の数値を得るには text（その後 bigint）にキャストします。直接 bigint にキャストすることはできません。クエリについては references/queries.md を参照してください。

ハイドレーションの状態

すべてのデータフローがハイドレーション済みかを確認するには、mz_internal.mz_hydration_statuses をクエリします。初回起動後にハイドレーションされていないオブジェクトがある場合、リソースの逼迫または設定の問題が考えられます。レプリカ列は LEFT JOIN してください。ハイドレーション対象となるレプリカがない場合、replica_id は NULL になります。内部結合では、これらのオブジェクトが表示されません。

メモリとリソース消費

• レプリカプロセスごとのメモリ／CPU 使用率には mz_internal.mz_cluster_replica_utilization
• 生のメモリ指標には mz_internal.mz_cluster_replica_metrics（こちらも（レプリカ、プロセス）ごとに 1 行）
• 最適化できる MV／インデックスの特定には mz_internal.mz_index_advice

ワーカースキュー（ワーカー間の CPU 不均衡）

WITH SKEW を使用して、あるワーカーに CPU／メモリ処理が偏っているオペレーターを見つけます。

これらは query_system_catalog ではなく、query ツールで実行してください。 EXPLAIN ANALYZE は cluster 引数で指定したクラスター上で実行されます。オブジェクトレベルのコマンドでは、MV／インデックスが存在するクラスターを指定する必要があります。間違えても、確実にエラーになるとは限りません。別の単一レプリカクラスターで実行した場合や、デフォルトクラスターにレプリカが 1 つある状態で query_system_catalog 経由で実行した場合、オブジェクトレベルのコマンドは空の結果を返し、「スキューなし」のように見えます。レプリカが複数ある場合は log source reads must target a replica で読み取りに失敗し、レプリカがない場合は has no replicas available to service request で失敗します。query を使わないと、このセクションは実行できません。

クラスター単位（調査対象のクラスターで実行）：

EXPLAIN ANALYZE CLUSTER CPU WITH SKEW

オブジェクト単位（MV とそのインデックスの両方で実行）：

EXPLAIN ANALYZE CPU WITH SKEW FOR MATERIALIZED VIEW <schema>.<mv_name>

EXPLAIN ANALYZE CPU WITH SKEW FOR INDEX <schema>.<index_name>

スキューがある場合は、スキューしているオペレーター（多くの場合、TopK／window／agg／join／distinct）を特定し、定義（SHOW CREATE ...）を確認して、具体的な SQL の変更を提案してください（ヒントの削除／調整、キー／パーティショニングのリファクタリング、または MV の書き換え）。

インデックスのアドバイス

Materialize に組み込まれているアドバイザー mz_internal.mz_index_advice をクエリします。出力されるヒントは次の 6 種類のみです：keep、drop unless queried directly、convert to a view、convert to a view with an index、convert to materialized view、add index。一部に絞り込むと、実際の推奨事項が黙って除外されます。それぞれの意味については references/queries.md を参照してください。

コスト分析（任意）

references/queries.md にあるコスト分析クエリを使用します（レプリカ単位の料金）。

推奨事項を記述する際は、必ずクレジットへの影響を数値で示してください（クレジットは Cloud の課金単位です。セルフマネージドの場合、同梱されているサイズには Cloud の数値が設定され、オペレーター定義のサイズにはオペレーターが設定した数値が使われます。デフォルトでは 0 なので、せいぜい相対的な重みとして提示してください）。

オブジェクトの依存関係

依存関係グラフを把握するには、mz_internal.mz_object_dependencies をクエリします。

ステップ 4：レポート — 分析の作成

references/report-template.md に従って、構造化された Markdown レポートを作成してください。レポートには、エグゼクティブサマリー、クラスターのトポロジー、デプロイ済みオブジェクト、パフォーマンス分析（フレッシュネス、ハイドレーション、使用率、ワーカースキュー、ソースとシンクの健全性）、コスト分析、インデックスのアドバイス、SQL レベルの分析、具体的な SQL を含む番号付きの推奨事項を含めます。

クラスターのトポロジーテーブルは、references/queries.md の Cluster Topology クエリと、同ファイルにある Current Compute Cost per Cluster のクレジット列から作成します。

推奨事項の書き方

具体的な SQL コマンドを必ず記載してください。 例：

良い例：

推奨事項： my_schema.unused_mv を通常のビューに変換して、メモリを節約します。

SHOW CREATE MATERIALIZED VIEW my_schema.unused_mv
DROP MATERIALIZED VIEW my_schema.unused_mv
CREATE VIEW my_schema.unused_mv AS <definition>

悪い例：

推奨事項： my_schema.unused_mv を通常のビューに変換することを検討してください。

トラブルシューティング手順書

問題を解決する具体的な SQL コマンドで必ず締めくくり、ユーザーの同意なしに実行してはいけません。 スケールアップやレプリカの追加には費用がかかり、オブジェクトの削除や変更は状態を失わせます。以下の修正はいずれも DDL であり、どちらのツールでも拒否されるため、コマンドをユーザーに提示してください。

「マテリアライズドビューが古いのはなぜですか？」

診断手順：

1. まず、MV のクラスターにレプリカがあるかどうかを確認します。mz_clusters と mz_cluster_replicas を LEFT JOIN します（クラスターとレプリカのクエリ）。replication_factor は、管理対象外のクラスターでは NULL になり、課金対象外のレプリカも把握できないため、使わないでください。レプリカのないクラスターでは何も実行されず、以下の手順もうまく機能しません。
2. mz_internal.mz_hydration_statuses を確認します。MV はハイドレーション済みですか？ また、同じクラスター上のほかのオブジェクトはすべてハイドレーション済みですか（非ハイドレーションオブジェクトのクエリをそのクラスターに限定します）？
3. mz_internal.mz_cluster_replica_status_history で、理由が oom-killed の最近の offline イベントを確認します。これは cgroup OOM キラー、ヒープリミッター、lgalloc のスピルディスクが満杯になった場合のいずれも対象です（レプリカ再起動のクエリを使用します。エミュレーターは理由を記録しないため、その場合は offline の件数を見て判断します）。OOM ループが発生していても、現在の状態は online で、利用率のサンプル値も低めに見えることがあります。OOM の大半はハイドレーション中に発生するため、手順 2 ですべてがハイドレーション済みであり、プロセスごとの最新の履歴行が online なら、ループは終わっています。ハイドレーション完了後も繰り返し停止する場合は、サイズの変更またはクラスター上の負荷軽減でしか定常状態のループを解消できません。
4. mz_internal.mz_cluster_replica_utilization を確認します。memory_percent が 100 に近い場合、RAM がいっぱいで、スワップ領域がある場合は、それ以降の増加分がスワップに回り、ハイドレーションの遅延や処理の遅れとして現れます。memory_percent が変わらない一方で heap_percent（RAM とスワップの合計を上限と比較した値）が増加している場合は、スワップが使用されています。100 に近づくと、次の急増でレプリカが停止します。いずれの場合も、スケールアップするか、MV を移動するか、クラスターが保持するものを減らしてください（以下の修正と手順 7 を参照）。
5. mz_internal.mz_source_statuses を確認します。上流ソースにエラーはありますか？
6. mz_internal.mz_materialization_lag で MV のラグを確認します（Freshness を参照）。
7. query ツールが利用できる場合は、MV のクラスターで EXPLAIN ANALYZE MEMORY FOR MATERIALIZED VIEW <schema>.<mv> を実行し、演算子ごとのメモリ使用量を確認して、コストの高い形状（大きな arrangement、インデックスのない結合、欠落した時間フィルター）を特定します。

よくある修正：

MV のクラスターにレプリカがない場合：

ALTER CLUSTER <cluster_name> SET (REPLICATION FACTOR 1)

-- Unmanaged cluster: add a replica directly
CREATE CLUSTER REPLICA <cluster_name>.r1 (SIZE = '<size>')

クラスターが過負荷の場合（メモリ／CPU 使用率が高い）：

-- Option A: Scale up the cluster (unmanaged: DROP and CREATE its replicas
-- at the bigger size instead)
ALTER CLUSTER <cluster_name> SET (SIZE = '<next_size_up>')

-- Option B: Move the MV to a different cluster
SHOW CREATE MATERIALIZED VIEW <schema>.<mv_name>
DROP MATERIALIZED VIEW <schema>.<mv_name>
CREATE MATERIALIZED VIEW <schema>.<mv_name> IN CLUSTER <new_cluster> AS <definition>

上流ソースが実行されていない場合：

SELECT name, status, error, last_status_change_at
FROM mz_internal.mz_source_statuses
WHERE status != 'running'

running 以外の状態がすべて障害を示すわけではなく、error が伴うのは stalled だけです。各状態の意味については、以下の「ソースは正常に動作していますか？」を参照してください。まず上流ソースの問題を修正してください。MV の鮮度はソースの健全性に依存します。

「クラスターのメモリが不足しているのはなぜですか？」

診断手順：

1. mz_internal.mz_cluster_replica_utilization でメモリ使用率を確認し、mz_cluster_replica_status_history で oom-killed イベント（レプリカの再起動）を確認します
2. mz_internal.mz_index_advice で、マテリアライズを解除できる MV を確認します
3. MV の定義に時間条件フィルターが不足していないか確認します
4. 冗長なインデックスがないか確認します
5. query ツールを利用できる場合は、問題が疑われるオブジェクトのクラスターで EXPLAIN ANALYZE MEMORY FOR MATERIALIZED VIEW <schema>.<mv>（または FOR INDEX <name>）を実行し、どの演算子が最も多くのメモリを使用しているか確認します。どの構成が原因なのかを特定する最も直接的な方法です。

一般的な対処方法：

マテリアライズする必要のない MV のマテリアライズを解除します：

SELECT o.name, o.type, sc.name AS schema_name, ia.hint, ia.details
FROM mz_internal.mz_index_advice ia
JOIN mz_catalog.mz_objects o ON ia.object_id = o.id
JOIN mz_catalog.mz_schemas sc ON o.schema_id = sc.id
WHERE ia.hint = 'convert to a view'

convert to a view with an index と convert to materialized view も、それぞれ異なる対処方法が必要なメモリに関する推奨事項です。この項目に対応する前に、推奨事項一式（references/queries.md のインデックスアドバイスクエリ）をすべて確認してください。

-- For each candidate:
SHOW CREATE MATERIALIZED VIEW <schema>.<mv_name>
DROP MATERIALIZED VIEW <schema>.<mv_name>
CREATE VIEW <schema>.<mv_name> AS <definition>

未使用のインデックスを削除します：

SELECT o.name, o.type, sc.name AS schema_name, ia.hint, ia.details
FROM mz_internal.mz_index_advice ia
JOIN mz_catalog.mz_objects o ON ia.object_id = o.id
JOIN mz_catalog.mz_schemas sc ON o.schema_id = sc.id
WHERE ia.hint = 'drop unless queried directly'

-- Verify with the user before dropping
DROP INDEX <schema>.<index_name>

クラスターをスケールアップします（非管理対象の場合は、レプリカを大きなサイズで DROP して CREATE し直します）：

ALTER CLUSTER <cluster_name> SET (SIZE = '<next_size_up>')

「ソースは正常ですか？／ソースのスナップショットの読み込みは完了していますか？」

診断手順：

1. mz_internal.mz_source_statuses でソースのエラーを確認します
2. mz_internal.mz_source_statistics で取り込みの進行状況を確認します
3. mz_internal.mz_materialization_lag でエンドツーエンドの遅延を確認します

一般的な対処方法：

ソースが実行されていない場合：

SELECT name, status, error
FROM mz_internal.mz_source_statuses
WHERE status != 'running'

ステータスは created（まだステータスが記録されていない）、starting、running、paused、stalled、dropped のいずれかです。ドキュメントには failed も記載されていますが、コードでは生成されません。error を伴うのは stalled のみです。Webhook と progress の行は常に running と表示されます。created と starting は一時的な正常状態です。paused はソースのクラスターにレプリカがないことを意味し、いくら待っても解消しません。

-- paused: give the source's cluster a replica
ALTER CLUSTER <cluster_name> SET (REPLICATION FACTOR 1)
-- unmanaged cluster: CREATE CLUSTER REPLICA <cluster_name>.r1 (SIZE = '<size>')

-- stalled/failed on bad credentials:
ALTER SECRET <secret_name> AS '<new_value>'

snapshot_committed が false の場合、ソースは初期スナップショットをまだ読み込んでいます。大きなソースでは正常な状態なので、完了するまで待ちます。また、ソースまたはレプリカの起動後約 2 分間は、カウンターがゼロのまま false と表示されます。mz_source_statistics の行がまったくないソースは一度も実行されていないため、待つのではなく、ステータスとクラスターにレプリカがあるかどうかを確認してください。一時停止中のソースには古い行が残るため、まず status を確認してください。

「環境はどのような状態ですか？」

次の順序で確認します：

1. mz_internal.mz_cluster_replica_statuses — ユーザークラスターのすべてのレプリカが準備完了で、mz_cluster_replica_status_history に最近の oom-killed がないか確認します
2. mz_internal.mz_source_statuses — すべてのソースが実行中か確認します
3. mz_internal.mz_sink_statuses — すべてのシンクが実行中か確認します
4. mz_internal.mz_cluster_replica_utilization — リソースの逼迫状況を確認します

「コストを抑えるには何を最適化できますか？」

1. mz_internal.mz_index_advice で最適化候補を確認します
2. クラスターの使用状況を確認し、過剰にプロビジョニングされていないか調べます
3. mz_catalog.mz_cluster_replica_sizes でクレジットレートを確認します

注記

• アクセスは RBAC によって制御されるため、認証情報でアクセスできるデータのみが表示されます。カタログには同じ制限が適用されません。オブジェクトへの権限が付与されていないロールでも、オブジェクトの一覧全体、すべてのビューと MV の definition、および mz_index_advice のすべてを読み取れます。RBAC が有効な場合、query と、自動ルーティングされないすべての読み取りには、実行先クラスターに対する USAGE も必要です（mz_catalog_server は PUBLIC に付与します）。RBAC チェックが有効かどうかは、デプロイとその構成によって異なります。SHOW enable_rbac_checks と SHOW enable_session_rbac_checks で確認できます（いずれかが on なら有効です）。
• 最新性の値は特定時点のスナップショットです。遅延が安定しているか増加しているかを確認するには、再実行してください。