データベースパフォーマンス改善の基盤

企業規模のシステム開発において、データベースのレスポンス遅延やCPU/メモリリソースの逼迫は、大半が非効率なSQLクエリに起因します。複雑な結合や動的なフィルタリングを含む問い合わせを最適化するには、構文レベルの理解とストレージエンジンが実際に取る処理フロー（実行プラン）の可視化が不可欠です。本稿では、Pythonスクリプトを用いてSQLの構文をプログラム的に分解し、実行プランを解釈してボトルネックを特定するワークフローを解説します。

PythonでのSQL構文分解

クエリチューニングの自動化を実現するには、自然言語のように見えるSQLを構文木（AST）またはトークン列にパースする必要があります。Pythonの生態系には複数のパーサが存在しますが、`sqlparse`はインストールの簡易性と軽量性から、解析パイプラインの前処理段階で広く利用されています。以下は、クエリから対象テーブル名と検索条件を抽出する実装例です。

import sqlparse
from sqlparse.sql import IdentifierList, Identifier, Where

def parse_query_metadata(raw_query: str) -> dict:
    """SQL文字列から対象テーブルとWHERE句を構造化して抽出する"""
    parsed_tree = sqlparse.parse(raw_query)[0]
    metadata = {
        "target_tables": [],
        "filter_clause": None,
        "is_complex": False
    }
    
    for token in parsed_tree.tokens:
        # FROM句のテーブル一覧を取得
        if isinstance(token, IdentifierList):
            metadata["target_tables"].extend(
                [str(ident).strip('"[]') for ident in token.get_identifiers()]
            )
        elif isinstance(token, Identifier) and token.ttype is None:
            table_name = str(token).split('.')[-1]
            if table_name not in metadata["target_tables"]:
                metadata["target_tables"].append(table_name)
                
        # WHERE条件の文字列抽出
        if isinstance(token, Where):
            metadata["filter_clause"] = str(token)
            
        # 結合やサブクエリの存在で複雑度フラグを立てる
        if token.ttype in (sqlparse.tokens.Keyword, sqlparse.tokens.DML):
            val = str(token).upper()
            if any(kw in val for kw in ("JOIN", "SUBQUERY", "UNION", "EXISTS")):
                metadata["is_complex"] = True
                
    return metadata

# 実行例
sample_sql = "SELECT e.emp_id, d.dept_name FROM hr.employees e JOIN hr.departments d ON e.dept_id = d.id WHERE e.hire_date > '2023-01-01'"
extracted_info = parse_query_metadata(sample_sql)
print(f"対象エンティティ: {extracted_info['target_tables']}")
print(f"検索制約: {extracted_info['filter_clause']}")
print(f"複雑クエリ判定: {extracted_info['is_complex']}")

このアプローチにより、文字列操作ではなく構造化データとしてSQLの骨格を取得できます。抽出されたメタデータは、インデックスカバレッジチェックや不要なテーブル参照の検知へとそのまま接続可能です。

実行プランの取得とデータ構造の解釈

構文解析が完了した後は、DBMSが実際にどのようにデータをスキャン・結合・ソートするかを確認します。現代のリレーショナルデータベース（MySQL 8.0以降、PostgreSQL 14以降など）は`EXPLAIN`コマンドの出力形式としてJSONをサポートしており、プログラム的な解析に非常に適しています。

import json

def fetch_json_plan(cursor, target_query: str) -> dict:
    """DBカーソルを介してJSON形式の実行プランを取得する"""
    # PostgreSQL: EXPLAIN (FORMAT JSON)
    # MySQL: EXPLAIN FORMAT=JSON
    explain_cmd = f"EXPLAIN (FORMAT JSON) {target_query}"
    cursor.execute(explain_cmd)
    raw_result = cursor.fetchone()
    
    if not raw_result:
        raise RuntimeError("実行プランの取得に失敗しました")
        
    plan_json = json.loads(raw_result[0])
    return plan_json

def check_scan_type(plan_data: dict) -> str:
    """プラン構造から主要なスキャンタイプを判定する"""
    # PGのJSONプラン構造を仮定
    stmt = plan_data.get("Planned Statement", [])
    if not stmt:
        return "UNKNOWN"
        
    first_node = stmt[0].get("Node Type", "")
    scan_type = stmt[0].get("Scan Type", "")
    cost = stmt[0].get("Total Cost", 0)
    
    if scan_type == "Seq Scan" and cost > 10000:
        return "FULL_TABLE_SCAN_HIGH_COST"
    elif first_node in ("Index Scan", "Index Only Scan", "Bitmap Index Scan"):
        return "INDEX_UTILIZED"
    else:
        return "OTHER_SCAN"

取得したJSONプランには、各ノードのコスト見積もり、アクセスメソッド、使用インデックス名、統計情報に基づく行数見積もりが含まれます。これらの値を閾値と比較することで、フルテーブルスキャンの発生やインデックスの未利用、見積もり行数と実際行数の大きな乖離（統計情報劣化）を自動的に検知できます。

計画的なクエリ改善アプローチ

実行プランから導き出された洞察に基づき、以下のような具体的な改善パターンの適用が有効です。

• インデックス戦略の見直し: 頻繁に`WHERE`や`JOIN`条件に登場する列に対して、単一カラム索引だけでなく、クエリの選択性と順序を考慮した複合索引（Composite Index）や部分索引（Partial Index）を構築します。
• 投影列の最小化: `SELECT *`の多用はネットワーク帯域の消費とメモリプールの負荷を増大させます。実際に必要なカラムのみを指定し、索引でカバレッジが取得できる状態（Covering Index）に近づけます。
• 論理表現の書き換え: 相関サブクエリは外部クエリごとに再評価される傾向があるため、可能であれば`JOIN`構文へ変換し、クエリ最適化器が最適な結合順序を選べるようにします。
• データパーティショニングの適用: 時系列ログや大規模トランザクション履歴では、パーティションキーを`WHERE`条件に含むことでパーティションプルーニングが効き、スキャン対象データを物理的に排除できます。

解析スクリプトと実行プラン評価ロジックを連携させることで、開発環境でのクエリレビューや本番環境のSlow Query Log監視を構造化できます。定型的なパフォーマンス劣化パターンに対しては、ルールベースの推奨事項を生成し、インデックス追加DDLやクエリリライト案を自動提案するパイプラインとして運用可能です。