【ITニュース解説】SQL Rewriting vs. Indexing: How AI-Powered Structural Optimization Achieves 20x Scalability Gains

この記事は、データベースの性能を向上させる主要な二つの手法、SQL Rewriting（SQLの書き換え）とIndexing（インデックスによる最適化）について、その効果とスケーラビリティ（拡張性）を比較した研究である。システムエンジニアにとって、データベースクエリの応答速度はアプリケーションの品質に直結するため、これらの最適化技術の理解は不可欠だ。特に、AIを活用したSQLFlashというツールを用いた構造的最適化が、データ量が増加しても安定した性能を維持する点で、いかに優れているかを解説する。単なるインデックス追加に留まらず、SQLの構造そのものを改善する重要性が強調されている。

この実験は、実際のビジネス状況を模倣した環境で、MySQLデータベースのクエリ性能を詳細に検証する目的で行われた。主な目的は二つ。一つは、異なるデータ規模において、SQL Rewritingとインデックス最適化がそれぞれどれほど性能に影響するかを分析すること。もう一つは、ビジネスデータの増加に伴い、これらの最適化手法がどれだけ長期的に効果を維持できるかを評価することである。特に、AIツールであるSQLFlashが提示するSQLの書き換え案が、性能向上にどれほど貢献するかを検証した。

実験には、業界で広く使われているリレーショナルデータベースMySQL 5.7が使用された。データはPythonスクリプトで生成された架空のビジネス取引データであり、顧客情報、取引記録、詳細、サービス記録、リスク監視など、複数のテーブルにまたがる複雑な構成を模倣している。これにより、実際の業務で発生するような、複数のテーブルを結合して情報を取得するクエリのパフォーマンスを評価できる環境を構築した。基幹テーブルのデータ量は、11,000件から最大500,000件まで段階的に増やし、データ規模が性能に与える影響を詳細に分析した。また、特定の期間に高リスク取引が集中するようにデータを設定し、性能ボトルネックを意図的に作り出した。

最適化の対象となったのは、リスク監視システムが特定した「マネーロンダリング」「詐欺」「異常な資金活動」といった高リスク取引を、特定の期間（2024年9月24日から26日）で検索するSQLクエリであった。このクエリは、データ量がわずか11,000件の段階で、実行に1分1.09秒もかかる「遅いSQL」として特定された。このSQLは、customer_master、transactions、txn_detailの三つのテーブルを結合し、さらにrisk_monitorテーブルの存在チェックをEXISTS句で行う複雑な構造を持っていた。特に、DATE_FORMAT関数を用いて日付を比較している点や、入れ子のサブクエリが多用されている点が、性能低下の主要因となっていた。

SQL Rewritingは、SQL文の構造そのものを変更し、データベースがより効率的に処理できるようにする手法だ。この研究では、SQLFlashによる最適化プロセスを以下の三段階で説明している。

最初の段階は、「Projection Pushdown（射影プッシュダウン）」と「Predicate Pushdown（述語プッシュダウン）」である。Projection Pushdownは、クエリに必要な列だけをデータの取得初期段階で選択することで、不要なデータの読み込みや転送を削減する。Predicate Pushdownは、フィルタリング条件をデータソースに近づけて適用することで、処理対象のデータ量を早い段階で大幅に減らす。これらの最適化により、元の61.09秒かかっていたクエリは44.35秒へと、約27%の改善を達成した。これは、主にデータスキャンと転送のボトルネックを解消した効果である。

次に、「Subquery Folding（サブクエリの結合化）」が実施された。これは、入れ子になったサブクエリを、よりシンプルで効率的なJOIN文に書き換えることで、データベースが複雑な論理を解釈したり一時的なデータを作成したりする手間を省く。この変更により、実行時間は44.35秒から0.81秒へと、98%以上という劇的な改善を達成した。構造的な複雑さと計算上の無駄が大きく削減された結果である。

最後に、「Implicit Conversion Fix（暗黙の型変換の修正）」が行われた。元のSQLでは、transaction_date列をDATE_FORMAT関数で文字列に変換してから日付範囲を比較していた。このような関数の利用は、データベースがインデックス（検索を速くする「目次」のようなもの）を効果的に使えなくする原因となる。修正では、関数を削除し、日付列を直接日付範囲（BETWEEN句）で比較するように変更した。これにより、インデックスが適切に利用可能となり、実行時間は0.81秒から0.47秒へとさらに短縮された。これは、インデックスの非効率性を解消したことによる効果である。

これらの構造的最適化を段階的に適用することで、元々1分以上かかっていたクエリの実行時間は、わずか0.47秒にまで短縮され、約130倍の性能向上を達成した。

インデックスは、データベーステーブル内の特定の列に作成されるデータ構造で、特定のデータを素早く検索するために用いられる。本記事では、SQL Rewriting後のSQLに対して、さらにインデックスを追加することで性能向上を試みた。具体的には、customer_masterテーブルにtransaction_dateとtransaction_noの複合インデックス（idx_cm_date_no）を、transactionsテーブルにtransaction_noとtransaction_dateの複合インデックス（idx_tx_no_date）を、そしてrisk_monitorテーブルにもtransaction_noとtransaction_dateの複合インデックス（idx_rm_no_date）を追加した。これらのインデックスは、WHERE句のフィルタリング条件やJOIN条件に合致するように設計され、データベースが全件スキャンすることなく、必要なデータに直接アクセスできるようにする。例えば、customer_masterテーブルのアクセスは、フルテーブルスキャンからインデックスを使ったレンジスキャンに変わり、スキャン行数が11,072行から81行へと劇的に削減された。同様に、risk_monitorテーブルのサブクエリもインデックスにより処理行数が大幅に減少し、その実行コストはほぼゼロにまで低減された。

実験では、以下の四つのシナリオで性能を比較した。

1. 元のSQL（インデックスなし）: 61秒。これが初期の性能基準となる。
2. 書き換え後のSQL（インデックスなし）: 0.47秒。SQL Rewriting単独で約130倍の高速化を達成し、インデックスがなくても大きな効果があることが示された。
3. 元のSQL（最適化されたインデックスあり）: 0.1秒。インデックス最適化だけでも、元の遅いSQLは大幅に改善された。
4. 書き換え後のSQL（最適化されたインデックスあり）: 0.01秒。SQL Rewritingとインデックス最適化を組み合わせることで、最も優れた性能（0.01秒）を達成した。これは、インデックス最適化された元のSQLと比較してもさらに10倍速い結果である。

データ量が増加した場合のスケーラビリティも検証された。データ量が11,000行から500,000行に増えても、SQL Rewritingされたクエリは0.01秒から0.2秒未満へと安定した性能を維持した。一方、元のSQLは4.19秒まで実行時間が増加し、データ量増加に対するパフォーマンスの悪化が顕著であった。この結果は、データ量が増えるにつれてインデックスのみの最適化では限界があることを明確に示している。構造的SQL最適化は、クエリ構造の改善、冗長な計算の排除、不要なデータアクセスの削減を通じて、データ量の増加に対しても安定した性能を維持する能力がある。

この実験は、SQL Rewritingによる構造的最適化が、インデックス最適化と比較して、より高い汎用性とデータ量の増加に対応できる持続可能なパフォーマンス向上をもたらすことを明確に示した。特に、将来的なデータ成長が見込まれるビジネスシステムにおいては、インデックスの追加だけに頼るのではなく、SQLの構造そのものを最適化する「構造的SQL最適化」をシステムの設計段階で優先的に考慮することが極めて重要である。戦略的な計画においては、インデックス最適化よりも構造的最適化を先行して実施することが推奨される。AIツール「SQLFlash」のようなツールは、経験の浅いエンジニアでも複雑なSQLのパフォーマンス問題を効率的に特定し、具体的な改善策を提供することで、開発プロセスの大幅な効率化に貢献する。手動でのSQL最適化は専門知識と時間が必要だが、AIの活用により、より少ない労力で一貫性のある高性能なデータベース運用が可能となる。