Rychlý start: Pomocník pro optimalizaci dotazů

GitHub Copilot pomáhá vývojářům optimalizovat dotazy a analyzovat kritické body výkonu, aniž by museli znát interní struktury databází, zejména vývojáři bez hlubších znalostí Transact-SQL (T-SQL). GitHub Copilot může rozdělit komplexní SQL, interpretovat plány provádění a navrhovat strategie indexování nebo příležitosti refaktoringu. Vývojáři můžou udržovat své aplikace funkční a výkonné a zároveň se soustředit na doručování funkcí.

Začínáme

Ujistěte se, že jste připojení k databázi a máte otevřené okno aktivního editoru s rozšířením MSSQL. Toto připojení umožňuje účastníkovi @mssql chatu porozumět kontextu vašeho databázového prostředí a umožnit přesné a kontextové návrhy. Bez připojení k databázi nebude účastník chatu mít schéma ani datový kontext, aby poskytoval smysluplné odpovědi.

Následující příklady používají AdventureWorksLT2022 ukázkovou databázi, kterou si můžete stáhnout z domovské stránky Ukázky microsoft SQL Serveru a projekty komunity .

Nejlepších výsledků dosáhnete, když upravíte názvy tabulek a schémat tak, aby odpovídaly vašemu vlastnímu prostředí.

Ujistěte se, že chat obsahuje předponu @mssql . Například zadejte @mssql svůj dotaz nebo výzvu. Tím zajistíte, že účastník chatu pochopí, že žádáte o pomoc související s SQL.

Optimalizace výkonu pomocí GitHub Copilotu

GitHub Copilot nabízí několik způsobů, jak vývojářům pomoct psát výkonný a produkční databázový kód bez nutnosti hlubších odborných znalostí při ladění dotazů nebo analýze plánu provádění. Ať už vytváříte nové funkce nebo zkoumáte problém s výkonem, Může GitHub Copilot zobrazit přehledy, doporučit optimalizace a pomoct restrukturalizovat dotazy, a to vše v rámci stávajícího pracovního postupu v editoru Visual Studio Code.

Tady jsou běžné případy použití a příklady toho, co se můžete zeptat prostřednictvím účastníka chatu.

Optimalizace dotazů

Pomocí GitHub Copilotu můžete identifikovat nedostatky v dotazech SQL nebo objektově-relačních mapování (ORM) a navrhnout způsoby zlepšení výkonu. GitHub Copilot vám pomůže s použitím osvědčených postupů T-SQL a ORM, od přepsání pomalých dotazů po doporučování indexů nebo zabránění proti vzorům, jako jsou kartézské spojení, na základě aktuálního kontextu.

Základní příklad

Optimize the following query:

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

Příklad vylepšení indexu

Suggest indexing improvements for this query:

SELECT ProductID
FROM SalesLT.SalesOrderDetail
WHERE Quantity > 100;

Příklad vylepšení připojení

Rewrite this query to avoid a Cartesian join. Make sure the new query follows T-SQL best practices:

SELECT * FROM Customers, Order;

Příklad vnořeného výběru

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')
    }
  }
});

Analýza plánu provádění

Plány provádění poskytují podrobný rozpis toho, jak modul SQL zpracovává dotazy. GitHub Copilot vám může pomoct interpretovat plány provádění, identifikovat kritické body, jako jsou vnořené spojení s smyčkami, a navrhovat vylepšení na základě skutečných vzorů dotazů a strategií indexování.

Jako příklad můžete použít následující dotaz k vygenerování plánu provádění pomocí možnosti Odhad/Skutečný plán v rozšíření 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;

Zahrňte co nejvíce kontextu výběrem dotazu z editoru a zahrnutím sqlplan souboru do okna chatu GitHub Copilot, jak je znázorněno na tomto snímku obrazovky.

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.

Jako příklad můžete použít následující dotaz k vygenerování plánu provádění pomocí možnosti Odhad/Skutečný plán v rozšíření 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);

Zahrňte co nejvíce kontextu výběrem dotazu z editoru a zahrnutím sqlplan souboru do okna chatu GitHub Copilot, jak je znázorněno na tomto snímku obrazovky.

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;

Restrukturalizace dotazů

Restrukturalizace dotazů pomocí běžných výrazů tabulek (CTE) může zlepšit čitelnost a udržovatelnost, zejména u složitých logik nebo vnořených poddotazů. GitHub Copilot vám může pomoct přepsat stávající dotazy tak, aby používaly CTE a zachovaly záměr a zlepšily srozumitelnost.

Příklad vnitřního výběru v kontextu 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;

Příklad klauzule HAVING pro CTE

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;

Příklad klauzule agregace pro 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;

Scénáře výkonu pro první kód

Při práci s ORM, jako jsou Entity Framework, Prisma nebo Sequelize, může dojít ke snížení výkonu, pokud dotazy nejsou optimalizovány. GitHub Copilot pomáhá zjišťovat a řešit problémy, jako jsou chybějící indexy, neefektivní filtrování a problémy N+1 v pracovních postupech založených na kódu.

Příklad prisma

In a Prisma project, how would you ensure that queries filtering by `OrderDate` in `SalesOrderHeader` are using indexes effectively?

Příklad 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?

Příklad Sequelize

In Sequelize, how do you restructure a query that fetches order history with product details to minimize N+1 query issues?

Pokud nám chcete pomoct upřesnit a vylepšit GitHub Copilot pro rozšíření MSSQL, odešlete zpětnou vazbu pomocí následující šablony problému Na GitHubu: Váš názor na GitHub Copilot

Při odesílání zpětné vazby zvažte následující:

Otestované scénáře – Dejte nám vědět, na které oblasti jste se zaměřili, například na vytváření schématu, generování dotazů, zabezpečení, lokalizaci.
Co dobře fungovalo – popište všechny zážitky, které se cítily hladce, užitečné nebo překročily vaše očekávání.
Problémy nebo chyby – Zahrňte všechny problémy, nekonzistence nebo matoucí chování. Snímky obrazovky nebo nahrávky obrazovky jsou užitečné hlavně.
Návrhy ke zlepšení – Sdílejte nápady na zlepšení použitelnosti, rozšíření pokrytí nebo vylepšení odpovědí GitHub Copilotu.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-11-19