GitHub Copilot は、データベース内部の専門知識を必要とせずに、開発者がクエリを最適化し、パフォーマンスのボトルネックを分析するのに役立ちます。特に、深い Transact-SQL (T-SQL) の専門知識を持たない開発者を支援します。 GitHub Copilot では、複雑な 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 のベスト プラクティスを適用するのに役立ちます。
基本的な例
Optimize the following query:
SELECT *
FROM SalesLT.SalesOrderHeader
WHERE OrderDate > '2023-01-01';
インデックスの改善の例
Suggest indexing improvements for this query:
SELECT ProductID
FROM SalesLT.SalesOrderDetail
WHERE Quantity > 100;
ジョイン改善例
Rewrite this query to avoid a Cartesian join. Make sure the new query follows T-SQL best practices:
SELECT * FROM Customers, Order;
入れ子構造のセレクトの例
Rewrite this Prisma query to avoid unnecessary nested selects and improve readability:
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 ファイルを含めることで、できるだけ多くのコンテキストを含めます。
According to the execution plan shared by my database expert, the following query is using a nested loop join which is affecting the performance of my app. Can you explain in simple terms why this might be happening? Additionally, suggest optimization strategies that could improve the query's performance.
次のクエリを例として使用して、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);
このスクリーンショットに示すように、エディターからクエリを選択し、GitHub Copilot チャット ウィンドウに sqlplan ファイルを含めることで、できるだけ多くのコンテキストを含めます。
Explain the execution plan for this query that performs a join with a filter on 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 を使用するように既存のクエリを書き直すのに役立ちます。
CTE への内部選択の例
Rewrite this query using common table expressions (CTEs) to improve clarity:
SELECT *
FROM (SELECT ProductID,
SUM(Quantity) AS TotalQuantity
FROM Sales
GROUP BY ProductID) AS SubQuery;
CTE へ HAVING 句の例
Rewrite the following query using a CTE (common table expression) to improve readability and maintainability:
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に対する集計句の例
Use a CTE to separate the aggregation logic from the filter condition in this query:
SELECT ProductID,
AVG(UnitPrice) AS AvgPrice
FROM SalesLT.SalesOrderDetail
GROUP BY ProductID
HAVING AVG(UnitPrice) > 50;
コード優先のパフォーマンス シナリオ
Entity Framework、Prisma、または続編などの ORM を使用する場合、クエリが最適化されていない場合、パフォーマンスが低下する可能性があります。 GitHub Copilot は、コード優先ワークフローでインデックスの不足、非効率的なフィルター処理、N+1 の問題などの問題を検出して解決するのに役立ちます。
Prisma の例
In a Prisma project, how would you ensure that queries filtering by `OrderDate` in `SalesOrderHeader` are using indexes effectively?
Entity Framework Core の例
Using Entity Framework Core, how can you analyze and optimize a LINQ query that retrieves the top 10 customers by total order value?
Sequelizeの例
In Sequelize, how do you restructure a query that fetches order history with product details to minimize N+1 query issues?
感想をお聞かせください
MSSQL 拡張機能の GitHub Copilot を改良および改善するために、次の GitHub 問題テンプレートを使用してフィードバックを送信します。 GitHub Copilot フィードバック
フィードバックを送信する場合は、次の内容を検討してください。
テスト済みのシナリオ – スキーマの作成、クエリの生成、セキュリティ、ローカライズなど、どの領域に重点を置いたかをお知らせください。
うまくいったこと - スムーズで役に立ち、期待を超えた経験について説明します。
問題またはバグ – 問題、不整合、または混乱を招く動作を含めます。 スクリーンショットや画面の記録は特に役立ちます。
改善の提案 – 使いやすさの向上、カバレッジの拡大、GitHub Copilot の応答の強化に関するアイデアを共有します。
関連コンテンツ
- Visual Studio Code 用 MSSQL 拡張機能のための GitHub Copilot
- クイックスタート: チャット機能とGitHub Copilotのインライン提案を使う
- クイック スタート: コードを生成する
- クイック スタート: スキーマ エクスプローラーとデザイナーを使用する
- クイック スタート: スマート クエリ ビルダーを使用する
- クイックスタート: ビジネスロジック解説機能の使い方
- クイック スタート: セキュリティ アナライザー
- クイック スタート: ローカライズと書式設定ヘルパー
- クイックスタート: テストとモックテスト作成のためにデータを生成する
- 制限事項と既知の問題