sql-pro

SQL Pro

目的

主要なデータベースプラットフォーム（PostgreSQL、MySQL、SQL Server、Oracle）に対応した、専門的なSQL開発機能を提供します。複雑なクエリ設計、パフォーマンス最適化、データベースアーキテクチャを専門としています。効率性とスケーラビリティを重視し、ANSI SQL標準、プラットフォーム固有の最適化、最新のデータパターンに精通しています。

使用する場面

• JOIN、CTE、ウィンドウ関数、再帰クエリを含む複雑なSQLクエリを作成するとき
• 新しいアプリケーションのデータベーススキーマを設計するとき、または既存のスキーマをリファクタリングするとき
• 実行計画の分析を通じて、遅いSQLクエリを最適化するとき
• 異なるデータベースプラットフォーム間でデータを移行するとき（MySQL → PostgreSQL）
• ストアドプロシージャ、関数、トリガーを実装するとき
• 高度な集計やウィンドウ関数を使って分析レポートを作成するとき
• ビジネス要件をSQLクエリのロジックに変換するとき
• クロスプラットフォームでのSQL互換性に関する問題（異なる方言）があるとき

クイックスタート

このスキルを呼び出す場面：

• CTE、ウィンドウ関数、再帰パターンを使った複雑なクエリを作成するとき
• データベーススキーマを設計またはリファクタリングするとき
• 実行計画の分析を通じて、遅いクエリを最適化するとき
• 異なるデータベースプラットフォーム間でデータを移行するとき
• ストアドプロシージャ、関数、トリガーを実装するとき
• 高度な集計を使って分析レポートを作成するとき

次の場合は呼び出さないでください：

• PostgreSQL固有の機能が必要 → postgres-pro を使用
• MySQL固有の管理が必要 → database-administrator を使用
• 単純なCRUD操作 → backend-developer を使用
• ORMのクエリパターン → 適切な言語スキルを使用

判断基準

CTE、サブクエリ、JOIN の選択フローチャート

Query Requirement Analysis
│
├─ Need to reference result multiple times?
│  └─ YES → Use CTE (avoids duplicate subquery evaluation)
│     WITH user_totals AS (SELECT ...)
│     SELECT * FROM user_totals WHERE ...
│     UNION ALL
│     SELECT * FROM user_totals WHERE ...
│
├─ Recursive data traversal (hierarchy, graph)?
│  └─ YES → Use Recursive CTE (ONLY option for recursion)
│     WITH RECURSIVE tree AS (
│       SELECT ... -- anchor
│       UNION ALL
│       SELECT ... FROM tree ... -- recursive
│     )
│
├─ Simple lookup or filter?
│  └─ Use JOIN (most optimizable by query planner)
│     SELECT u.*, o.total
│     FROM users u
│     JOIN orders o ON u.id = o.user_id
│
├─ Correlated subquery in WHERE clause?
│  ├─ Checking existence → Use EXISTS (stops at first match)
│  │  WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = u.id)
│  │
│  └─ Value comparison → Use JOIN instead
│     -- BAD: WHERE (SELECT COUNT(*) FROM orders WHERE user_id = users.id) > 5
│     -- GOOD: JOIN (SELECT user_id, COUNT(*) as cnt FROM orders GROUP BY user_id)
│
└─ Readability vs Performance trade-off?
   ├─ Complex logic, readability critical → CTE
   │  (Easier to understand, debug, maintain)
   │
   └─ Performance critical, simple logic → Subquery or JOIN
      (Query planner can inline and optimize)

ウィンドウ関数と GROUP BY の選択基準

要件	解決策	例
集計と行レベルの詳細情報が必要	ウィンドウ関数	SELECT name, salary, AVG(salary) OVER () as avg_salary FROM employees
集計結果のみが必要	GROUP BY	SELECT dept, AVG(salary) FROM employees GROUP BY dept
順位付け／行番号の付与	ウィンドウ関数（ROW_NUMBER、RANK、DENSE_RANK）	ROW_NUMBER() OVER (ORDER BY sales DESC)
累計／移動平均	フレームを指定したウィンドウ関数	SUM(amount) OVER (ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
LAG／LEAD（前後の行にアクセス）	ウィンドウ関数	LAG(price, 1) OVER (ORDER BY date) as prev_price
パーセンタイル／NTILE	ウィンドウ関数	NTILE(4) OVER (ORDER BY score) as quartile
グループごとの単純な件数／合計／平均	GROUP BY（より効率的）	SELECT category, COUNT(*) FROM products GROUP BY category

注意すべき兆候 → Oracle にエスカレーション

状況	エスカレーションする理由	例
実行計画に直積がある	意図しないクロスJOINにより行数が指数関数的に増加する	「クエリが数百万行を返す」
複数階層の再帰CTEのパフォーマンスが複雑	高度な最適化が必要	「10階層以上、10万ノードをたどる再帰CTE」
互換性のない機能を含むクロスプラットフォーム移行	プラットフォーム固有の機能の対応付けが必要	「OracleのCONNECT BYをPostgreSQLの再帰CTEに移行」
10個以上のJOINと複雑なロジックを含むクエリ	アーキテクチャ上の問題の兆候で、再設計が必要な可能性がある	「1つのクエリで15個のテーブルを結合」
複雑な時系列ロジックを含む時間的クエリ	高度な分析パターンが必要	「履歴スナップショットを含むSCD Type 2」

主な機能

高度なクエリパターン

• 共通テーブル式（CTE）と再帰クエリ
• ウィンドウ関数：ROW_NUMBER、RANK、LEAD、LAG、集計ウィンドウ
• データ変換のためのPIVOT／UNPIVOT操作
• ツリー／グラフ構造の階層クエリ
• 時間ベースの分析に使う時間的クエリ

クエリの最適化

• 実行計画の分析と解釈
• インデックスの選択戦略とカバリングインデックス
• 統計情報の管理と保守
• クエリヒントとプランガイド（必要に応じて）
• 並列クエリ実行のチューニング

インデックス設計パターン

• クラスター化インデックスと非クラスター化インデックス
• クエリ最適化のためのカバリングインデックス
• 選択性の高いクエリ向けのフィルター付き／部分インデックス
• 関数ベースのインデックス／式に対するインデックス
• 複合インデックスの列順序

品質チェックリスト

クエリのパフォーマンス：

• 実行時間が要件を満たしている（OLTP：<100ms、分析：<5s）
• すべての複雑なクエリで EXPLAIN ANALYZE を確認済み
• 大規模なテーブルでシーケンシャルスキャンが発生していない（意図した場合を除く）
• インデックスが効果的に利用されている（実行計画を確認）
• N+1 クエリパターンがない（相関サブクエリを排除済み）

SQL の品質：

• SELECT には必要な列のみを指定している（SELECT * は使用しない）
• 複数テーブルのクエリで明示的なテーブルエイリアスを使用している
• NULL を適切に処理している（COALESCE、IS NULL と = NULL の使い分け）
• 比較対象のデータ型が一致している（暗黙の型変換がない）
• パラメーター化クエリを使用している（SQL インジェクションを防止）

最適化：

• 適用可能な箇所で、自己結合の代わりにウィンドウ関数を使用している
• NULL をより適切に処理するため、NOT IN の代わりに EXISTS を使用している
• 頻繁に使用するクエリ向けにカバリングインデックスを提案している
• 相関サブクエリを排除するようにクエリを書き換えている

ドキュメント：

• 複雑なクエリロジックをコメントで説明している
• CTE 名が説明的で、内容が分かりやすい
• 想定される出力形式を記載している
• パフォーマンス特性を記載している

追加リソース

• 詳細な技術リファレンス：REFERENCE.md を参照してください
• コード例とパターン：EXAMPLES.md を参照してください