Dory を使用して遅い SQL クエリをデバッグする

低速クエリのデバッグは、SQL 全体を書き換える前に高価な部分を分離すると最も効果的です。スキャン範囲を縮小し、結合を検証し、集計と並べ替えを検査して、AI にレビュー可能な代替案を求めます。

このワークフローを使用する場合

• SQL が遅いかタイムアウトです。
• クエリがスキャンするデータが多すぎます。
• 結合、グループ化、または順序付けにはコストがかかります。
• ClickHouse モニタリングで遅いクエリが表示される。
• AI が生成した SQL は正しいですが、コストがかかりすぎます。

1. 遅いクエリを特定します。

ClickHouse の場合は、Monitoring から始めます。

• 過去 1 時間または過去 1 日の遅いクエリを確認します。
• P95レイテンシとQPMを検査します。
• ユーザー、データベース、クエリ タイプ、またはキーワードでフィルタリングします。
• SQL を SQL コンソールにコピーします。

他のデータベースの場合は、SQL コンソール期間、エラー、行数から始めます。

2. データ範囲を減らす

SELECT ...
FROM your_table
WHERE event_time >= now() - INTERVAL 1 DAY
LIMIT 100;

クエリに時間範囲があり、可能な場合はパーティションまたは並べ替えフィールドを使用し、必要な列のみを選択し、無制限の SELECT *を回避していることを確認してください。

3. 複合体 SQL の分割

各部分を個別に検証します。

1. ベースフィルター。
2. 入力サイズを結合します。
3. 集計ロジック。
4. 最終注文または上位 N。

これは、フィルタリング、結合、グループ化、並べ替えがボトルネックになっているかどうかを特定するのに役立ちます。

4. AI にパフォーマンスの書き換えを依頼する

This ClickHouse SQL is slow. Optimize it without changing the metric definition:
- only analyze the last 7 days
- avoid SELECT *
- use event_time filtering
- keep the final output columns
Explain why each change may be faster.

5. 前後の比較

両方のバージョンを実行し、期間、行数、メトリック値、スキャン範囲、保守性を比較します。結果が異なる場合は、最適化されたクエリを採用する前に調査してください。

一般的な原因

FAQ

AI が結果を変えたらどうなるでしょうか?

採用しないでください。フィルタ、結合タイプ、重複排除、および集計粒度を比較します。

ClickHouse について最初に確認すべきことは何ですか?

時間範囲、パーティション キー、並べ替えキー、行の読み取り、バイトの読み取り、グループ ディメンション。

データベース管理者はどのような場合に関与する必要がありますか?

クエリでスキーマの変更、インデックスまたはパーティションの変更、クラスターのチューニング、または運用ワークロードの調整が必要な場合は、DBAのヘルプを求めてください。

次のステップ

• Ask AI で SQL を生成する で書き換えます。
• Build Charts from SQL を使用してビジュアルを構築します。
• 実証済みのクエリを 保存されたクエリ に保存します。