query-optimization

クエリの最適化

SQL Server と Azure SQL Database 向けの T-SQL クエリ最適化に関する包括的なガイドです。検証済みの根拠に基づいて最適化します。対象には、スキーマ、データ型、インデックス、行数、パーティション分割、実行プラン、許可されている変更の種類が含まれます。

必須のワークフロー

1. スキーマを最初に検証する

書き換え、インデックス、ヒントを提案する前に、次の項目を検証するか、不明として明示してください。

• SQL Server のバージョン、エディション、互換性レベル、および該当する場合は Azure SQL のティア。
• クエリ／プロシージャの全文、パラメーター値、実行頻度、目標実行時間。
• テーブル、ビュー、一時テーブル、テーブル変数、TVF の DDL。
• 結合、フィルター、グループ化、並べ替え、一時テーブルの各列のデータ型。長さ、精度、スケール、照合順序、NULL 許容性も含めます。
• 既存のインデックス、制約、統計情報の更新時期、パーティション関数／スキーム、行数。
• オブジェクトがローカルか、リンクサーバー／リモートソースか。
• 許可されている変更の種類：クエリの書き換え、新しいインデックス、大規模テーブルのインデックス変更、統計情報の更新、ステージングテーブル、計算列、またはコード変更なし。

../_shared/optimization-intake.md と ../_shared/assumption-tracker.md を使用してください。重要な事実が不足している場合は、最終的な指示ではなく、条件付きのガイダンスと診断情報を提示してください。

2. 根本的なボトルネックを特定する

可能であれば、実際の実行プランと STATISTICS IO, TIME を使用してください。推定プランの割合だけでなく、測定された影響に基づいて調査結果に優先順位を付けます。

• 論理読み取り数または読み取られた行数が多い。
• 推定値と実測値の行数に大きな差がある。
• 非SARGableな述語や適切なアクセスパスの欠如によって発生するスキャン。
• 実行回数が多いことで増大するキー検索。
• 不適切な推定や並べ替えの欠如によるソート／ハッシュ／ウィンドウ処理のスピル。
• 述語や結合をリンクサーバーにプッシュできないリモートクエリ。

詳細な .sqlplan の調査には、tsql-master:execution-plan-analysis を読み込んでください。

3. SARGability と型の不一致を修正する

SARGable な述語は、順序付けされたインデックスアクセスを利用できます。インデックス列に関数を適用したり、変換したりすることは避けてください。

非SARGable	より安全なパターン
WHERE YEAR(OrderDate) = 2026	WHERE OrderDate >= '20260101' AND OrderDate < '20270101'
WHERE LEFT(Name, 3) = 'ABC'	WHERE Name LIKE 'ABC%'
WHERE Amount * 1.1 > 1000	WHERE Amount > 1000 / 1.1
WHERE CONVERT(date, Dt) = @d	WHERE Dt >= @d AND Dt < DATEADD(day, 1, @d)
WHERE VarcharCol = 123	WHERE VarcharCol = '123'

実際のデータ型を確認してください。構文上はSARGableな述語でも、パラメーター、一時列、結合キーの型または照合順序が間違っていると、スキャンが発生する場合があります。

4. 結合の変更を立証する

選択列が1つのテーブルに由来するという理由だけで、結合を削除または置き換えてはいけません。次の点を立証してください。

• 結合によって行が絞り込まれますか？ ベースの行数と結合後の行数を比較し、信頼済みの外部キーを確認します。
• 結合によって行数が増えますか？ 結合キーの一意性と、参照先テーブル内の重複を確認します。
• EXISTS に置き換えられますか？ 存在確認だけが必要で、行数の増加を避けたい場合はセミ結合を使用します。
• 外部結合は維持されていますか？ WHERE 句の述語によって、LEFT JOIN が意図せず内部結合に変わることがあります。

結合削除の検証はプルーフハーネス内で行い、両方向の EXCEPT で同等性を検証してください。references/rewrite-proof-harnesses.md を参照してください。

5. 一時テーブルとステージングの型を確認する

一時テーブルは適切な最適化手段であることが多いですが、型が不適切だと、見えにくい変換が発生する可能性があります。

一時テーブルを使用または推奨する前に、次の点を確認してください。

• ステージング列の型をソースのメタデータと比較します。
• 結合／フィルター列の文字列長と照合順序を一致させます。
• 数値の精度／スケールと日付／時刻の精度を一致させます。
• 行数が妥当な場合は、読み込み後に適切なクラスター化または非クラスター化インデックスを追加します。
• 段階的な最適化で正確なカーディナリティが必要な場合は、一時テーブルの統計情報を更新します。

型の不一致は、プラン分析やインデックスの推奨を無効にする可能性があるため、最優先で指摘してください。references/rewrite-proof-harnesses.md のチェッカーを使用してください。

6. 書き換えテンプレートを選択する

確認済みのボトルネックに対処する、最も変更の少ない書き換えを選択します。

状況	テンプレート
巨大な結合の前に選択性の高い述語がある	選択性の高いキーを先にステージングし、そのステージにインデックスを作成してから結合します。
巨大な詳細テーブルを後で集約している	グループ化によって意味が保たれる場合は、早期に集約します。
結合が存在確認のみを行う	行を生成する結合を EXISTS に置き換えます。
異なる列にまたがる OR	重複を防ぐ条件を付けて、UNION ALL の分岐に分割します。
あらゆるケースに対応するオプション述語	動的 SQL または対象を絞った再コンパイルを使用します。頻繁に実行する処理では Col = @p OR @p IS NULL を避けます。
安全でないパーティション述語	パーティション列に対する、型を直接指定した範囲条件に書き換えます。
テーブル変数／TVF による不適切な推定	バージョンとワークロードに応じて、一時テーブル、インライン TVF、または再コンパイルを使用します。

行数の削減と意味の同等性が証明されていない限り、フィルターされていない巨大なテーブルをステージングしたり、早期に集約したりしないでください。

パラメーター感度

パラメーター スニッフィングは、ある値でコンパイルされたプランが、まったく異なる値に対して再利用されると発生します。修正を適用する前に、偏りとコンパイル時／実行時の値を確認してください。

オプション	最適な用途	注意点
OPTION (RECOMPILE)	実行頻度が低い、または変動が大きいステートメント	コンパイル CPU が増加し、プランは再利用されません。
OPTIMIZE FOR (@p = value)	代表的な値が安定している場合	データの変化に伴って効果が低下する可能性があります。
OPTIMIZE FOR UNKNOWN	平均的な分布で問題ない場合	どのケースでも中程度の性能にとどまる可能性があります。
動的 SQL	オプション述語や多様なクエリ形状	安全なパラメーター化が必要です。
Query Store ヒント	SQL Server 2022+ または Azure SQL で、コードを変更できない場合	性能の後退を監視してください。
PSP 最適化	SQL Server 2022+ で互換性レベル 160 の場合	適用対象となるパターンに限られます。

実行プランの確認項目

次の演算子と警告を確認してください。

プラン上の証拠	考えられる対処
残余述語を伴うスキャン	SARGability、キーの順序、またはフィルター付きインデックスを修正します。
読み取り行数が多いシーク	選択性の高いキー列を追加するか、残余述語を書き換えます。
キー検索が何度も繰り返される	クエリをカバーするか、先に外側の行数を減らします。
ソートまたはハッシュのスピル	推定を修正し、行数／行幅を減らすか、順序に適合するインデックスを追加します。
列に対する CONVERT_IMPLICIT	パラメーター／一時テーブル／ソースのデータ型を一致させます。
推定値が 10 倍以上ずれている	統計、偏り、テーブル変数、述語、制約を確認します。
欠落インデックスの警告	候補としてのみ扱い、既存のインデックスやワークロードと統合します。

統計とカーディナリティ

古くなった推定や不十分な推定が証拠から示される場合は、統計に関する作業を行います。

DBCC SHOW_STATISTICS('dbo.TableName', 'IndexOrStatsName');
UPDATE STATISTICS dbo.TableName IndexOrStatsName WITH FULLSCAN;

大規模なパーティション テーブルでは、増分統計とフィルター付き統計を評価してください。メンテナンス時間帯やブロッキングを考慮せずに、本番環境で広範なフルスキャンの更新を実行しないでください。

出力形式

次の内容で回答してください。

1. 受付状況：確認済み、未確認、否定済み、診断が必要。
2. ボトルネックの証拠：プランノード、読み取り、行数、推定値、警告。
3. 推奨方針：書き換え、インデックス／統計の変更、または診断。許可された変更の種類ごとに分けて記載します。
4. 検証手順：結果の同等性と変更前後の性能指標。
5. リスク：パラメーター感度、書き込みオーバーヘッド、ブロッキング、パーティションの安全性、リモートプッシュダウン。

参考資料

• ../_shared/optimization-intake.md - 必須の受付チェックリスト。
• ../_shared/assumption-tracker.md - 仮定のステータスに関するプロトコル。
• references/rewrite-proof-harnesses.md - 結合の検証、一時テーブルの型チェッカー、書き換えテンプレート。
• references/dmv-diagnostic-queries.md - パフォーマンス分析用の DMV クエリ。