SQL Pro

コアワークフロー

1. スキーマ分析 - データベース構造、インデックス、クエリパターン、パフォーマンスボトルネックをレビュー
2. 設計 - CTE、ウィンドウ関数、適切なJOINを使用してセットベースの操作を作成
3. 最適化 - 実行プランを分析し、カバリングインデックスを実装し、テーブルスキャンを排除
4. 検証 - EXPLAIN ANALYZE を実行し、大規模テーブルでシーケンシャルスキャンがないことを確認します。クエリが100ms未満のターゲットを満たさない場合、インデックス選択またはクエリ再作成で反復してから先に進みます
5. ドキュメント化 - クエリの説明、インデックスの根拠、パフォーマンスメトリクスを提供

リファレンスガイド

コンテキストに基づいて詳細なガイダンスを読み込みます：

トピック	リファレンス	読み込むタイミング
クエリパターン	references/query-patterns.md	JOIN、CTE、サブクエリ、再帰クエリ
ウィンドウ関数	references/window-functions.md	ROW_NUMBER、RANK、LAG/LEAD、分析
最適化	references/optimization.md	EXPLAIN プラン、インデックス、統計、チューニング
データベース設計	references/database-design.md	正規化、キー、制約、スキーマ
方言の違い	references/dialect-differences.md	PostgreSQL vs MySQL vs SQL Server の仕様

クイックリファレンス例

CTE パターン

-- 高コストのサブクエリロジックを分離して再利用と可読性を向上
WITH ranked_orders AS (
    SELECT
        customer_id,
        order_id,
        total_amount,
        ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) AS rn
    FROM orders
    WHERE status = 'completed'          -- JOINの前にフィルタリング
)
SELECT customer_id, order_id, total_amount
FROM ranked_orders
WHERE rn = 1;                           -- 顧客ごとの最新の完了注文

ウィンドウ関数パターン

-- パーティション内の累計と順位 — セルフJOINは不要
SELECT
    department_id,
    employee_id,
    salary,
    SUM(salary)  OVER (PARTITION BY department_id ORDER BY hire_date) AS running_payroll,
    RANK()       OVER (PARTITION BY department_id ORDER BY salary DESC) AS salary_rank
FROM employees;

EXPLAIN ANALYZE 解釈

-- PostgreSQL: 実際の行数と推定値を確認するために常にANALYZEを使用
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '30 days';

出力で確認する主な項目：

• Seq Scan on large table → インデックスを追加または修正
• actual rows ≫ estimated rows → ANALYZE <table> を実行して統計を更新
• Buffers: shared hit vs read → 高い read カウントはキャッシュ/インデックスの欠落を示す

最適化前後の例

-- 前：相関サブクエリ、行ごとに1回の実行（遅い）
SELECT order_id,
       (SELECT SUM(quantity) FROM order_items oi WHERE oi.order_id = o.id) AS item_count
FROM orders o;

-- 後：単一の集約JOIN（高速）
SELECT o.order_id, COALESCE(agg.item_count, 0) AS item_count
FROM orders o
LEFT JOIN (
    SELECT order_id, SUM(quantity) AS item_count
    FROM order_items
    GROUP BY order_id
) agg ON agg.order_id = o.id;

-- サポート用カバリングインデックス（クエリで使用されるすべての列を含む）
CREATE INDEX idx_order_items_order_qty
    ON order_items (order_id)
    INCLUDE (quantity);

制約事項

実施する必要がある

• 最適化を推奨する前に実行プランを分析
• 行ごとの処理ではなくセットベースの操作を使用
• クエリ実行の早い段階でフィルタリングを適用（可能ならJOIN前）
• 存在確認には COUNT ではなく EXISTS を使用
• 比較と集約で NULL を明示的に処理
• 頻繁なクエリ用にカバリングインデックスを作成
• 本番スケールのデータボリュームでテスト

実施してはならない

• 本番クエリで SELECT * を使用
• セットベースの操作が機能する場合にカーソルを使用
• 特定の方言をターゲットとする場合、プラットフォーム固有の最適化を無視
• データボリュームとカーディナリティを考慮せずにソリューションを実装

出力テンプレート

SQLソリューションを実装する際は、以下を提供してください：

1. インラインコメント付きの最適化されたクエリ
2. 根拠付きの必要なインデックス
3. 実行プラン分析
4. パフォーマンスメトリクス（前後比較）
5. 該当する場合、プラットフォーム固有の注記