LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

データベース性能チューニングとは何か

データベース性能チューニングとは、稼働中のデータベースで発生している処理の遅延を、計測データに基づいて特定し、インデックス設計やSQL文の見直しなどの手段で処理速度を高める作業を指します。対象は新規に設計するデータベースではなく、すでに稼働し利用者から遅延の指摘が出ている環境です。

PostgreSQL公式ドキュメントは、クエリの実行計画を確認するEXPLAINコマンドについて、プランナーが生成した実行計画をツリー構造で表示し、各処理段階の推定コスト・推定行数を示すと説明しています^*1。この推定値と実測値の差を見ることが、チューニングの出発点になります。

性能チューニングを検討する場面は、利用者の増加によってページの表示や処理完了までの時間が伸びた場合、蓄積データが増えて集計処理が遅くなった場合、新機能の追加で複雑なSQLが実行されるようになった場合など複数あります。いずれの場合も、感覚での対処ではなく計測データに基づく原因特定が前提になります。

スロークエリログ・実行計画・待機イベント——ボトルネックの見つけ方

ボトルネックの特定は、まず処理時間のかかっているSQL文を絞り込む工程から始まります。MySQL公式ドキュメントは、スロークエリログについて、実行時間が指定した閾値（デフォルトは10秒）を超えたSQL文を記録する仕組みと説明し、実行時間・ロック取得時間・検査行数・送信行数を各クエリごとに記録すると示しています^*2。

スロークエリログで対象を絞り込んだ後は、そのSQL文の実行計画を確認します。実行計画とは、データベース管理システム（DBMS）がSQL文をどのような手順で処理するかを表す情報です。PostgreSQL公式ドキュメントによれば、EXPLAINは推定コストと推定行数を示すのに対し、EXPLAIN ANALYZEは実際にクエリを実行し、実測の処理時間と実測行数を追加で表示します^*1。推定値と実測値の差が大きい場合、統計情報が実態とずれている可能性を示します。

実行計画だけでは見えない待機の実態を捉える手段として、待機イベントの計測があります。MySQL公式ドキュメントは、Performance Schemaの待機イベント集計テーブルについて、ロックやI/O処理などの待機時間をイベント名別・スレッド別に集計し、発生回数・合計待機時間・平均待機時間を記録する仕組みと説明しています^*3。処理そのものではなくロック待ちやディスクI/O待ちが遅延の主因である場合、この計測がなければ原因を誤って特定するおそれがあります。

インデックス設計——B-tree・複合・カバリングの使い分け

インデックスとは、テーブル内の特定の列を高速に検索できるようにする索引構造です。開発者向けにSQLインデックスを解説するMarkus Winand氏のWebサイト「Use The Index, Luke」（2010年公開）は、B-treeインデックス（バランス木構造の索引）を基本形として解説し、複数列を組み合わせる複合インデックス（Concatenated Keys）、検索に必要な列をインデックス自体に含めて元テーブルへのアクセスを避けるカバリングインデックス（Index-Only Scan）を代表的な手法として紹介しています^*4。

PostgreSQL公式ドキュメントは、B-treeインデックスがデフォルトのインデックス型であり、等価比較（=）や範囲比較（<、>、BETWEEN）に対応すると説明しています^*5。前方一致のパターンマッチング（例：col LIKE 'foo%'）にも対応しますが、前方が固定されない検索（col LIKE '%bar'）には対応しないとされています^*5。この特性を踏まえずインデックスを設定しても、想定した検索条件で使われないケースが生じます。

複合インデックスは、検索条件やソート条件で複数列を組み合わせて使う場合に効果を発揮します。ただし、列の順序が検索条件と一致していない場合はインデックスが効率的に使われないことがあり、単純に複数列を並べれば良いわけではありません。カバリングインデックスは、インデックスのみで検索結果を返せるようにすることで元テーブルへのアクセス（テーブルアクセス）を省略できる仕組みですが、インデックスに含める列が増えるほどインデックス自体のサイズと更新コストが増加します。

SQL書き換え・N+1解消・統計情報更新——代表的なチューニング手法

インデックス設計と並ぶ代表的な手法が、SQL文そのものの書き換えです。実行計画を確認した結果、インデックスが存在していても使われていない場合、SQL文の記述方法が原因になっていることがあります。列に関数や演算を適用した条件式（例：日付列に対する加工処理）は、インデックスが利用されない典型的な要因の一つです。

N+1問題も見直し対象になりやすい構造です。N+1問題とは、1件の親データを取得した後、関連する子データを件数分繰り返し個別に取得してしまう処理パターンを指します。アプリケーション側の実装に起因することが多く、関連データを1回のSQL文でまとめて取得するよう書き換えることで、発行されるSQL文の件数を減らせます。

統計情報の更新も欠かせない手法です。PostgreSQL公式ドキュメントは、ANALYZEコマンドについて、テーブルの内容に関する統計情報（値の分布・最頻値のリストなど）を収集してシステムカタログに格納し、この統計情報の精度がプランナーの実行計画選択に影響すると説明しています^*6。大量データの一括投入や削除の直後は統計情報が実態と食い違い、非効率な実行計画が選ばれる要因になります。

• インデックス追加・変更（B-tree・複合・カバリングの適用）
• SQL文の書き換え（関数適用条件の見直し・JOIN方法の変更）
• N+1問題の解消（関連データの一括取得への変更）
• 統計情報の更新（大量データ変更後のANALYZE実行）

正規化と非正規化のトレードオフ——整合性を崩さず速くする判断

すでに正規化されたテーブル構造を持つ稼働中データベースでは、性能改善の選択肢として非正規化（意図的にデータを重複させてテーブル結合を減らす手法）が検討されることがあります。参照処理でテーブル結合の負荷が高い場合、集計済みのサマリーテーブルを別途用意して参照系の処理をそこから読む構成に変更する方法があります。

非正規化は読み取り性能を高める一方、データの重複箇所が増えるため、更新時に複数箇所を同期させる処理が必要になります。同期処理を誤ると、テーブル間でデータが食い違う不整合が発生するおそれがあります。稼働中システムに対して非正規化を適用する場合は、更新処理への影響範囲を洗い出した上で、整合性を保つ仕組み（トリガーやバッチ処理での同期など）を併せて設計する必要があります。

過剰チューニングの弊害——計測なきインデックス追加のリスク

性能チューニングでは、対策を追加すればするほど良くなるわけではありません。インデックスは検索処理を速くする一方、データの追加・更新・削除のたびにインデックス自体も更新する処理が発生します。検索頻度が低く更新頻度が高いテーブルに多数のインデックスを設定すると、更新処理の負荷が増加し、全体の処理時間が悪化する場合があります。

この弊害を避ける原則は、計測結果に基づいてから対策を講じることです。実行計画で使われていないインデックスを放置したまま新しいインデックスを追加すると、不要な更新コストだけが積み重なります。定期的に、各インデックスの利用状況を確認し、使われていないインデックスの削除を検討することも性能チューニングの一部です。

失敗コストの観点でも計測は重要です。本番環境で検証せずにインデックスを追加した結果、想定していなかった実行計画（インデックスを使わない全件走査など）が選ばれ、むしろ処理時間が悪化する事例があります。変更後は実行計画と実測時間を確認し、処理時間が短縮したことを確かめる工程が欠かせません。

外注時の委託範囲——診断・改修・監視伴走の切り分け

データベース性能チューニングを外注する場合、委託範囲は大きく3つの段階に分けられます。どこまでを外部に委託するかによって、発注側に求められる準備と関与度が変わります。

診断のみを委託する場合、発注側には改善提案を実装する技術力が別途必要です。改修まで委託する場合でも、業務上重要な処理（決済・在庫更新など）に関わるSQL文の変更は、業務ロジックへの影響を発注側が確認できる体制を維持することが欠かせません。この作業を内製で完結させるには、SQL・実行計画の読み方・対象DBMSの内部構造という3領域の知識を持つ人材が必要になり、ボトルネック調査から改修まで一人で担うには相応の期間を要します。

監視伴走まで委託範囲に含めるかどうかは、チューニング後も継続的にデータ量が増加する事業か、一度の改修で十分な事業かによって判断が変わります。データ量が右肩上がりに増える事業では、半年後・1年後に再びボトルネックが発生する可能性があり、継続的な計測体制を持つ委託先の有無が中長期的な安定運用に影響します。

発注側が準備すべき情報

性能チューニングを外注する際、発注側が事前に用意する情報の精度が診断の速さと的確さを左右します。最低限整理しておきたい情報は次の通りです。

• 遅延が発生している業務処理の内容（画面名・バッチ処理名・発生時間帯）
• 現在のDBMS製品とバージョン、テーブル数・主要テーブルのデータ量規模
• スロークエリログ・実行計画を取得できる権限、または取得済みログの提供可否
• 直近のデータ量の増加傾向（過去との比較で遅延が悪化しているか）
• 改修内容を検証できるステージング環境の有無

ログ取得の権限が用意されていない場合、委託先は原因の特定作業から入る前に、まず計測環境を整える工程が必要になり、着手までの期間が延びます。本番環境に近いステージング環境がない場合、改修の効果検証を本番環境で直接行うリスクを伴うため、事前に検証環境を用意できるかを発注側で確認しておくことが望まれます。

LASSICのデータベース性能チューニング支援

LASSICはIT事業部において、元請（プライムベンダー）としてシステムの保守・運用を受託する体制を持ちます。性能チューニングは診断だけで終わらせず、改修後の稼働状況を継続的に確認できる体制と一体で提供することを重視しています。

まとめ：性能チューニング外注を成功させる3つの判断軸

本稿では、データベース性能チューニングの外注における進め方を整理しました。要点を3つに集約すると次の通りです。第一に、チューニングはスロークエリログ・実行計画・待機イベントといった計測データからボトルネックを特定する作業を起点にします。第二に、インデックス設計・SQL書き換え・統計情報更新は代表的な手法ですが、過剰なインデックスは更新性能を悪化させるトレードオフを伴うため計測結果に基づいた判断が必要です。第三に、外注では診断・改修・監視伴走のどこまでを委託するかを発注前に切り分け、稼働環境の情報を整理して共有することが、的確な改善につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：PostgreSQL Global Development Group「PostgreSQL Documentation – Using EXPLAIN」（postgresql.org）
2. *2　出典：Oracle「MySQL 8.4 Reference Manual – The Slow Query Log」（dev.mysql.com）
3. *3　出典：Oracle「MySQL 8.4 Reference Manual – Performance Schema Wait Event Summary Tables」（dev.mysql.com）
4. *4　出典：Markus Winand「Use The Index, Luke」（2010年公開・運営中）（use-the-index-luke.com）
5. *5　出典：PostgreSQL Global Development Group「PostgreSQL Documentation – Index Types」（postgresql.org）
6. *6　出典：PostgreSQL Global Development Group「PostgreSQL Documentation – ANALYZE」（postgresql.org）

Tweet