クイックスタート: クエリオプティマイザーアシスタント (プレビュー)

2025-05-19

GitHub Copilot は、特に T-SQL に関する深い専門知識を持たない開発者が、データベース内部を master することなく、クエリを最適化し、パフォーマンスのボトルネックを分析するのに役立ちます。複雑な SQL を分解し、実行プランを解釈し、インデックス作成戦略やリファクタリングの機会を提案し、開発者は機能の提供に集中しながらアプリの機能とパフォーマンスを維持できます。

始めましょう

データベースに接続されていて、MSSQL 拡張機能でアクティブなエディターウィンドウが開かれていることを確認します。この接続により、 @mssql チャット参加者はデータベース環境のコンテキストを理解できるため、正確でコンテキストに対応した提案が可能になります。データベース接続がないと、チャット参加者は意味のある応答を提供するスキーマまたはデータコンテキストを持ちません。

次の例では、 AdventureWorksLT2022 サンプルデータベースを使用します。このデータベースは、 Microsoft SQL Server サンプルとコミュニティプロジェクトのホームページからダウンロードできます。

最適な結果を得るには、独自の環境に合わせてテーブル名とスキーマ名を調整します。

チャットに @mssql プレフィックスが含まれていることを確認します。たとえば、「 @mssql 」と入力し、その後に質問またはプロンプトを入力します。これにより、チャット参加者は、SQL 関連のサポートを求めていることを理解できます。

GitHub Copilot を使用してパフォーマンスを最適化する

GitHub Copilot には、開発者がクエリチューニングや実行プラン分析に関する深い専門知識を必要とせずに、パフォーマンスの高い運用対応のデータベースコードを記述するのに役立つ複数の方法が用意されています。新しい機能を構築する場合でも、パフォーマンスの問題を調査する場合でも、GitHub Copilot では、Visual Studio Code の既存のワークフロー内で、分析情報の表示、最適化の推奨、クエリの再構築を行うことができます。

チャット参加者から質問できる一般的なユースケースと例を次に示します。

クエリの最適化

GitHub Copilot を使用して、SQL または ORM クエリの非効率性を特定し、パフォーマンスを向上させる方法を提案します。低速クエリの書き換えからインデックスの推奨、デカルト結合などのアンチパターンの回避まで、GitHub Copilot は、現在のコンテキストに基づいて T-SQL と ORM のベストプラクティスを適用するのに役立ちます。

次のクエリを最適化します。

SELECT *
FROM SalesLT.SalesOrderHeader
WHERE OrderDate > '2023-01-01';

このクエリのインデックス作成の機能強化を提案します。

SELECT ProductID
FROM SalesLT.SalesOrderDetail
WHERE Quantity > 100;

デカルト結合を回避するために、このクエリを書き直します。新しいクエリが T-SQL のベストプラクティスに従っていることを確認します。

SELECT * FROM Customers, Order;

不要な入れ子になった選択を回避し、読みやすさを向上させるために、この Prisma クエリを書き換えます。

const orders = await prisma.salesOrderHeader.findMany({
  where: {
    orderDate: {
      gt: new Date('2023-01-01')
    }
  }
});

実行プランの分析

実行プランでは、SQL エンジンがクエリを処理する方法の詳細な内訳が提供されます。 GitHub Copilot は、実行プランを解釈し、入れ子になったループ結合などのボトルネックを特定し、実際のクエリパターンとインデックス作成戦略に基づいて改善を提案するのに役立ちます。

次のクエリを例として使用して、MSSQL 拡張機能の [推定/実際のプラン] オプションを使用して実行プランを生成できます。

SELECT soh1.SalesOrderID AS OrderA,
       soh2.SalesOrderID AS OrderB,
       soh1.TotalDue AS TotalA,
       soh2.TotalDue AS TotalB
FROM SalesLT.SalesOrderHeader AS soh1
CROSS JOIN SalesLT.SalesOrderHeader AS soh2
WHERE soh1.TotalDue < soh2.TotalDue
ORDER BY soh2.TotalDue DESC;

ヒント

エディターからクエリを選択し、GitHub Copilot チャットウィンドウに sqlplan ファイルを含めることで、できるだけ多くのコンテキストを含めるようにしてください。

データベースエキスパートが共有する実行プランによると、次のクエリは入れ子になったループ結合を使用しており、アプリのパフォーマンスに影響を与えています。なぜこれが起こっているのかを簡単な言葉で説明できますか? さらに、クエリのパフォーマンスを向上させる可能性のある最適化戦略を提案します。

次のクエリを例として使用して、MSSQL 拡張機能の [推定/実際のプラン] オプションを使用して実行プランを生成できます。

SELECT c1.CustomerID,
       c1.LastName,
       c2.CustomerID AS MatchingCustomerID,
       c2.LastName AS MatchingLastName
FROM SalesLT.Customer AS c1
     INNER JOIN SalesLT.Customer AS c2
         ON c1.LastName = c2.LastName
        AND c1.CustomerID <> c2.CustomerID
OPTION (LOOP JOIN);

ヒント

TotalDue でフィルターを使用して結合を実行するこのクエリの実行プランについて説明します。

SELECT c.CustomerID,
       c.FirstName,
       c.LastName,
       soh.SalesOrderID,
       soh.TotalDue
FROM SalesLT.Customer AS c
     INNER JOIN SalesLT.SalesOrderHeader AS soh
         ON c.CustomerID = soh.CustomerID
WHERE soh.TotalDue > 500;

クエリの再構築

共通テーブル式 (CTE) を使用してクエリを再構築すると、特に複雑なロジックや入れ子になったサブクエリの読みやすさと保守性が向上します。 GitHub Copilot は、意図を維持し、明確さを向上させながら、CTE を使用するように既存のクエリを書き直すのに役立ちます。

わかりやすくするために、共通テーブル式 (CTEs) を使用してこのクエリを書き直します。

SELECT *
FROM (SELECT ProductID,
             SUM(Quantity) AS TotalQuantity
      FROM Sales
      GROUP BY ProductID) AS SubQuery;

読みやすさと保守容易性を向上させるために、CTE (共通テーブル式) を使用して次のクエリを書き換えます。

SELECT soh.CustomerID,
       COUNT(*) AS OrderCount
FROM SalesLT.SalesOrderHeader AS soh
WHERE soh.OrderDate > '2022-01-01'
GROUP BY soh.CustomerID
HAVING COUNT(*) > 5;

CTE を使用して、このクエリのフィルター条件から集計ロジックを分離します。

SELECT ProductID,
       AVG(UnitPrice) AS AvgPrice
FROM SalesLT.SalesOrderDetail
GROUP BY ProductID
HAVING AVG(UnitPrice) > 50;

Code-First パフォーマンスシナリオ

Entity Framework、Prisma、または続編などの ORM を使用する場合、クエリが最適化されていない場合、パフォーマンスが低下する可能性があります。 GitHub Copilot は、コード優先ワークフローでインデックスの不足、非効率的なフィルター処理、N+1 の問題などの問題を検出して解決するのに役立ちます。

Prisma プロジェクトでは、OrderDateのSalesOrderHeaderによるクエリフィルター処理でインデックスが効果的に使用されるようにするにはどうすればよいですか?
Entity Framework Core を使用して、注文の合計値で上位 10 人の顧客を取得する LINQ クエリを分析して最適化するにはどうすればよいですか?
続編では、N+1 クエリの問題を最小限に抑えるために、製品の詳細で注文履歴をフェッチするクエリをどのように再構築しますか?

フィードバック: クエリオプティマイザーアシスタント

MSSQL 拡張機能の GitHub Copilot を改良および改善するために、次の GitHub 問題テンプレートを使用してフィードバックを送信します。 GitHub Copilot フィードバック

フィードバックを送信する場合は、次の内容を検討してください。

テスト済みのシナリオ – スキーマの作成、クエリの生成、セキュリティ、ローカライズなど、どの領域に重点を置いたかをお知らせください。
うまくいったこと - スムーズで役に立ち、期待を超えた経験について説明します。
問題またはバグ – 問題、不整合、または混乱を招く動作を含めます。スクリーンショットや画面の記録は特に役立ちます。
改善の提案 – 使いやすさの向上、カバレッジの拡大、GitHub Copilot の応答の強化に関するアイデアを共有します。

次の方法で共有

クイック スタート: クエリ オプティマイザー アシスタント (プレビュー)

始めましょう

GitHub Copilot を使用してパフォーマンスを最適化する

クエリの最適化

実行プランの分析

クエリの再構築

Code-First パフォーマンス シナリオ

フィードバック: クエリ オプティマイザー アシスタント

関連コンテンツ

フィードバック

その他のリソース

クイックスタート: クエリオプティマイザーアシスタント (プレビュー)

Code-First パフォーマンスシナリオ

フィードバック: クエリオプティマイザーアシスタント