複雑なSQL。
わかりやすい成果。

修正したクエリを検証し、性能を比較する方法

SQLを変更する前に、正しい結果の基準を記録しておくと役立ちます。対象は、列の構成、抽出ルール、データの粒度、許容される重複、合計の計算方法です。検証用の例には、小規模なスキーマ、匿名化したレコード、期待する結果を含めます。この一式があれば、構文エラーと、レポートの解釈の誤りを切り分けやすくなります。

最適化の検証は二つの部分から成ります。まず、元のクエリと変更後のクエリの結果について、行数、キー、指標の照合用合計値、判断の難しい例を比較します。次に、合意したデータ量での測定結果を比較します。行が欠落している速い応答は、有用な最適化の成果とは認められません。

• DBMSのバージョン、クエリのパラメーター、代表的なテーブルのデータ量を記載します。
• 実行計画、測定条件、同時に発生していた負荷に関する情報を保存します。
• インデックスを変更する場合は、提案するコマンドと関連する制約を説明します。
• 最終的な説明では、修正したロジック、得られた効果、残っているボトルネックを分けて記載します。

PostgreSQLのEXPLAIN ANALYZEモードは、調査対象のクエリを実際に実行します。このため、データを変更する操作や負荷の大きいデータ抽出に使用する際は、事前に合意します。準備したテスト用コピーの使用が望ましいです。実測データを伴わない実行計画だけでも初期分析には役立ちますが、実際の業務シナリオで得られる結果の検証の代わりにはなりません。

DBMS間でSQLロジックを移行する際に照合すること

レポートやプロシージャの移行は、合意したデータに対する動作で評価します。正常に実行できることに加え、欠損値、型変換、丸め、日付、時間の境界の処理ルールを確認します。見た目が似たクエリでも、結合条件やフィルターのわずかな変更によって最終的な合計値が変わることがあります。

移行のための検証用資料一式

1. パラメーターと期待する結果の説明を添えた、元のSQLまたはプロシージャのコード。
2. 使用するテーブルの構造、列の型、制約、他の関数への依存関係。
3. 通常のデータと境界条件のデータの例：レコードの欠落、重複、空の値、日付の切り替わり、負またはゼロの金額。
4. これらの例に対する元のシステムの結果と、重要な業務ルールの説明。
5. 実行条件：頻度、データ量、許容時間、アクセス制限。

プロシージャがデータを変更する場合は、操作の順序、エラー処理、実行が完了しなかった後のテーブルの状態を別途検討します。レポート用のデータ抽出では、文書単位、文書の明細行単位、対象グループ単位など、結果の粒度が同じであることを確認します。クエリを書き換える際に、これらのレベルを気付かれないまま入れ替えてはいけません。

移行後は、SQLスクリプト、変更点の一覧、検証結果を保存しておくと役立ちます。未解決の依存関係は明記します。例えば、呼び出す関数が提供されていない場合や、フィールドの入力ルールが不明な場合です。この一覧があれば、具体的な疑問点から作業を再開でき、不要な業務データやアクセス権を渡すことなく、今後の検証について合意できます。