SQL コードレビュー

${selection} (または選択範囲がない場合はプロジェクト全体) の包括的な SQL コードレビューを実施し、セキュリティ、パフォーマンス、保守性、データベースのベストプラクティスに焦点を当てます。

🔒 セキュリティ分析

SQL インジェクション対策

-- ❌ CRITICAL: SQL インジェクションの脆弱性
query = "SELECT * FROM users WHERE id = " + userInput;
query = f"DELETE FROM orders WHERE user_id = {user_id}";

-- ✅ SECURE: パラメータ化クエリ
-- PostgreSQL/MySQL
PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?';
EXECUTE stmt USING @user_id;

-- SQL Server
EXEC sp_executesql N'SELECT * FROM users WHERE id = @id', N'@id INT', @id = @user_id;

アクセス制御と権限管理

• 最小権限の原則: 必要最小限の権限のみを付与
• ロールベースアクセス: ユーザー権限ではなくデータベースロールを使用
• スキーマセキュリティ: 適切なスキーマの所有権とアクセス制御
• 関数・プロシージャのセキュリティ: DEFINER vs INVOKER 権限の確認

データ保護

• 機密データ露出防止: 機密列を含むテーブルで SELECT * を避ける
• 監査ログ: 機密操作が確実にログされている
• データマスキング: ビューまたは関数を使用して機密データをマスク
• 暗号化: 機密データの暗号化されたストレージを確認

⚡ パフォーマンス最適化

クエリ構造の分析

-- ❌ BAD: 非効率なクエリパターン
SELECT DISTINCT u.* 
FROM users u, orders o, products p
WHERE u.id = o.user_id 
AND o.product_id = p.id
AND YEAR(o.order_date) = 2024;

-- ✅ GOOD: 最適化された構造
SELECT u.id, u.name, u.email
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE o.order_date >= '2024-01-01' 
AND o.order_date < '2025-01-01';

インデックス戦略レビュー

• 欠落インデックス: インデックスが必要な列を特定
• 過剰なインデックス: 未使用または冗長なインデックスを検出
• 複合インデックス: 複雑なクエリ用の複数列インデックス
• インデックス保守: 断片化または廃止されたインデックスの確認

JOIN の最適化

• JOIN タイプ: 適切な JOIN タイプの確認 (INNER vs LEFT vs EXISTS)
• JOIN 順序: より小さい結果セットを最初に処理するよう最適化
• 直積: 欠落 JOIN 条件を識別して修正
• サブクエリ vs JOIN: 最も効率的なアプローチを選択

集約とウィンドウ関数

-- ❌ BAD: 非効率な集約
SELECT user_id, 
       (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) as order_count
FROM orders o1
GROUP BY user_id;

-- ✅ GOOD: 効率的な集約
SELECT user_id, COUNT(*) as order_count
FROM orders
GROUP BY user_id;

🛠️ コード品質と保守性

SQL スタイルと書式

-- ❌ BAD: 不適切な書式とスタイル
select u.id,u.name,o.total from users u left join orders o on u.id=o.user_id where u.status='active' and o.order_date>='2024-01-01';

-- ✅ GOOD: 清潔で読みやすい書式
SELECT u.id,
       u.name,
       o.total
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = 'active'
  AND o.order_date >= '2024-01-01';

命名規則

• 一貫した命名: テーブル、列、制約が一貫したパターンに従う
• 説明的な名前: データベースオブジェクトの明確で意味のある名前
• 予約語: データベース予約語をIdentifierとして使用しない
• 大文字小文字: スキーマ全体での一貫した大文字小文字の使用

スキーマデザインレビュー

• 正規化: 適切な正規化レベル (過度または不足した正規化を避ける)
• データ型: ストレージとパフォーマンスのための最適なデータ型選択
• 制約: PRIMARY KEY、FOREIGN KEY、CHECK、NOT NULL の適切な使用
• デフォルト値: 列への適切なデフォルト値

🗄️ データベース固有のベストプラクティス

PostgreSQL

-- JSON データに JSONB を使用
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- JSONB クエリ用の GIN インデックス
CREATE INDEX idx_events_data ON events USING gin(data);

-- 複数値列のための配列型
CREATE TABLE tags (
    post_id INT,
    tag_names TEXT[]
);

MySQL

-- 適切なストレージエンジンを使用
CREATE TABLE sessions (
    id VARCHAR(128) PRIMARY KEY,
    data TEXT,
    expires TIMESTAMP
) ENGINE=InnoDB;

-- InnoDB のために最適化
ALTER TABLE large_table 
ADD INDEX idx_covering (status, created_at, id);

SQL Server

-- 適切なデータ型を使用
CREATE TABLE products (
    id BIGINT IDENTITY(1,1) PRIMARY KEY,
    name NVARCHAR(255) NOT NULL,
    price DECIMAL(10,2) NOT NULL,
    created_at DATETIME2 DEFAULT GETUTCDATE()
);

-- 分析用列ストア インデックス
CREATE COLUMNSTORE INDEX idx_sales_cs ON sales;

Oracle

-- 自動インクリメント用のシーケンスを使用
CREATE SEQUENCE user_id_seq START WITH 1 INCREMENT BY 1;

CREATE TABLE users (
    id NUMBER DEFAULT user_id_seq.NEXTVAL PRIMARY KEY,
    name VARCHAR2(255) NOT NULL
);

🧪 テストと検証

データ整合性チェック

-- 参照整合性を検証
SELECT o.user_id 
FROM orders o 
LEFT JOIN users u ON o.user_id = u.id 
WHERE u.id IS NULL;

-- データ一貫性の確認
SELECT COUNT(*) as inconsistent_records
FROM products 
WHERE price < 0 OR stock_quantity < 0;

パフォーマンステスト

• 実行プラン: クエリ実行プランをレビュー
• ロードテスト: 現実的なデータ量でクエリをテスト
• ストレステスト: 並行負荷下でのパフォーマンスを確認
• 回帰テスト: 最適化が機能を破損しないことを確認

📊 一般的なアンチパターン

N+1 クエリ問題

-- ❌ BAD: アプリケーションコードでの N+1 クエリ
for user in users:
    orders = query("SELECT * FROM orders WHERE user_id = ?", user.id)

-- ✅ GOOD: 単一の最適化クエリ
SELECT u.*, o.*
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

DISTINCT の過度な使用

-- ❌ BAD: DISTINCT が JOIN の問題を隠蔽
SELECT DISTINCT u.name 
FROM users u, orders o 
WHERE u.id = o.user_id;

-- ✅ GOOD: DISTINCT なしの適切な JOIN
SELECT u.name
FROM users u
INNER JOIN orders o ON u.id = o.user_id
GROUP BY u.name;

WHERE 句での関数の誤用

-- ❌ BAD: 関数がインデックスを使用できない
SELECT * FROM orders 
WHERE YEAR(order_date) = 2024;

-- ✅ GOOD: 範囲条件がインデックスを使用
SELECT * FROM orders 
WHERE order_date >= '2024-01-01' 
  AND order_date < '2025-01-01';

📋 SQL レビューチェックリスト

セキュリティ

• すべてのユーザー入力がパラメータ化されている
• 文字列連結による動的 SQL 構築がない
• 適切なアクセス制御と権限が設定されている
• 機密データが適切に保護されている
• SQL インジェクション攻撃ベクトルが排除されている

パフォーマンス

• 頻繁にクエリされる列にインデックスが存在する
• 不要な SELECT * ステートメントがない
• JOIN が最適化され、適切なタイプを使用している
• WHERE 句が選択的でインデックスを使用している
• サブクエリが最適化されているか JOIN に変換されている

コード品質

• 一貫した命名規則がある
• 適切な書式とインデントがある
• 複雑なロジックに意味のあるコメントがある
• 適切なデータ型が使用されている
• エラーハンドリングが実装されている

スキーマデザイン

• テーブルが適切に正規化されている
• 制約がデータ整合性を強制している
• インデックスがクエリパターンをサポートしている
• 外部キーリレーションシップが定義されている
• デフォルト値が適切である

🎯 レビュー出力形式

Issue テンプレート

## [優先度] [カテゴリ]: [簡潔な説明]

**場所**: [テーブル/ビュー/プロシージャ名と該当行番号]
**問題**: [問題の詳細な説明]
**セキュリティリスク**: [該当する場合 - インジェクションリスク、データ露出など]
**パフォーマンスへの影響**: [クエリコスト、実行時間への影響]
**推奨事項**: [コード例を含む具体的な修正]

**修正前**:
```sql
-- 問題のある SQL

修正後:

-- 改善された SQL

期待される改善: [パフォーマンス向上、セキュリティの利益]

### 概要評価
- **セキュリティスコア**: [1-10] - SQL インジェクション対策、アクセス制御
- **パフォーマンススコア**: [1-10] - クエリ効率、インデックス使用法
- **保守性スコア**: [1-10] - コード品質、ドキュメント
- **スキーマ品質スコア**: [1-10] - デザインパターン、正規化

### トップ 3 優先アクション
1. **[重大なセキュリティ修正]**: SQL インジェクション脆弱性に対処
2. **[パフォーマンス最適化]**: 欠落インデックスを追加またはクエリを最適化
3. **[コード品質]**: 命名規則とドキュメント化を改善

データベースに依存しない実用的な推奨事項を提供することに注力しながら、プラットフォーム固有の最適化とベストプラクティスを強調してください。