Megosztás a következőn keresztül:

Intelligens lekérdezésfeldolgozási funkciók részletesen

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseFelügyelt Azure SQL-példánySQL-adatbázis a Microsoft Fabricben

Ez a cikk részletes leírást tartalmaz a különböző intelligens lekérdezésfeldolgozási (IQP) funkciókról, kibocsátási megjegyzésekről és további részletekről. Az intelligens lekérdezésfeldolgozási (IQP) szolgáltatáscsalád olyan széles körű hatással rendelkező funkciókat tartalmaz, amelyek minimális implementálási erőfeszítéssel javítják a meglévő számítási feladatok teljesítményét.

A számítási feladatokat automatikusan jogosulttá teheti az intelligens lekérdezések feldolgozására az adatbázis megfelelő kompatibilitási szintjének engedélyezésével. Ezt a Transact-SQL használatával állíthatja be. Egy adatbázis kompatibilitási szintjének beállítása például AZ SQL Server 2022 (16.x) értékre:

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Az új verziókkal bevezetett változásokról további információt a következő témakörben talál:

Csoport módú adaptív illesztések

A következőkre vonatkozik: SQL Server (AZ SQL Server 2017-től kezdve (14.x)), Azure SQL Database

A köteg mód adaptív illesztés funkciójával a kivonat illesztési vagy beágyazott hurkok összekapcsolási módszerének kiválasztását elhalaszthatja , amíg az első bemenetet be nem vizsgálta egyetlen gyorsítótárazott terv használatával. Az Adaptív illesztés operátor egy küszöbértéket határoz meg, amellyel eldönthető, hogy mikor váltson a Beágyazott Hurok tervre. Ezért a terv dinamikusan válthat jobb illesztési stratégiára a végrehajtás során.

További információkért, beleértve az adaptív illesztések kompatibilitási szintjének módosítása nélküli letiltását, olvassa el az Adaptív illesztések ismertetése című témakört.

Felcserélt végrehajtás MSTVFs esetén

A következőkre vonatkozik: SQL Server (AZ SQL Server 2017-től kezdve (14.x)), Azure SQL Database

A többutas táblaértékű függvények (MSTVF) olyan felhasználó által definiált függvények, amelyek képesek paraméterek elfogadására, több T-SQL-utasítás végrehajtására és RETURN egy táblára.

Az átfedéses végrehajtás segít a munkaterhelés teljesítményproblémáiban, amelyek az MSTVF-ekhez társított rögzített számosságbecslések miatt merülnek fel. Az interleaved végrehajtás során a függvény tényleges sorszámait használjuk a jobb tájékozottabb alsóbb rétegbeli lekérdezésterv-döntések meghozatalához.

Az MSTVF-ek rögzített számosság-becslése 100 az SQL Server 2014 (12.x) verziótól kezdődően, és 1 az ennél korábbi SQL Server-verziók esetében.

Az interleaved végrehajtás megváltoztatja az egy lekérdezéses végrehajtás optimalizálási és végrehajtási fázisai közötti egyirányú határt, és lehetővé teszi, hogy a tervek a módosított számosságbecslések alapján alkalmazkodjanak. Az optimalizálás során, ha az adatbázismotor egy többutas táblaértékű függvényeket (MSTVF-eket) használó, többutas végrehajtásra jelölt feladattal találkozik, az optimalizálás szünetel, végrehajtja a vonatkozó részösszeget, rögzíti a pontos számosságbecsléseket, majd folytatja az optimalizálást az alsóbb rétegbeli műveletekhez.

Az alábbi képen egy élő lekérdezési statisztika kimenete látható, amely egy teljes végrehajtási terv egy részhalmaza, amely az MSTVF-ekből származó rögzített számosságbecslések hatását mutatja be

Láthatja a tényleges sorfolyamatot és a becsült sorokat. A tervnek három figyelemre méltó területe van (a folyamat jobbról balra halad):

  • Az MSTVF táblavizsgálat rögzített becslése 100 sor. Ebben a példában azonban 527 597 sor halad át ezen az MSTVF-táblavizsgálaton, ahogyan az élő lekérdezési statisztikákban látható 527597 ténylegesen 100 becsült - tehát a rögzített becslés jelentősen torz.
  • A Beágyazott hurkok műveletnél feltételezik, hogy az illesztés külső oldaláról csak 100 sor kerül visszaadásra. Az MSTVF által visszaadott sorok nagy száma miatt valószínűleg jobban jár egy másik illesztő algoritmussal.
  • A Kivonategyezés műveletnél figyelje meg a kis figyelmeztető szimbólumot, amely ebben az esetben a lemezre való kiömlést jelzi.

Végrehajtási terv sorfolyamatának diagramja a becsült sorokhoz képest.

Hasonlítsa össze az előző tervet azzal a tényleges tervvel, amelyet az interleaved végrehajtás engedélyezésével hoztak létre.

Szálankénti végrehajtási terv diagramja.

  • Az MSTVF táblavizsgálata mostantól pontos számosságbecslést tükröz. Figyelje meg a táblavizsgálat és a többi művelet átrendezését is.
  • Az illesztési algoritmusokat illetően ehelyett a Beágyazott hurok műveletről hash Match műveletre váltottunk, ami optimálisabb a nagyszámú sor miatt.
  • Figyelje meg azt is, hogy többé nincsenek kiömlésfigyelmeztetések, mivel az MSTVF táblavizsgálatából származó valódi sorok száma alapján több memóriát biztosítunk.

Két szálon futó végrehajtásra jogosult utasítások

Az MSTVF-re hivatkozó utasításoknak az interleaved végrehajtásban jelenleg csak olvashatónak kell lenniük, és nem lehetnek részei adatmódosítási műveletnek. Emellett az MSTVF-k nem jogosultak az interleaved végrehajtásra, ha nem használnak futásidejű állandókat.

Átfedő végrehajtás előnyei

Általánosságban elmondható, hogy minél nagyobb a eltérés a becsült és a tényleges sorok száma között, annál nagyobb a teljesítményre gyakorolt hatás az alsóbb rétegbeli tervműveletek számával együtt.

Általánosságban elmondható, hogy az interleaved végrehajtás előnyös az olyan lekérdezések esetén, ahol:

  • Nagy eltérés van a köztes eredményhalmaz (ebben az esetben az MSTVF) becsült és tényleges sorainak száma között.

  • A teljes lekérdezés pedig érzékeny a köztes eredmény méretének változására. Ez általában akkor fordul elő, ha a lekérdezési tervben egy összetett struktúra van az alstruktúra felett.

    Az MSTVF alapszintű SELECT * szolgáltatása nem élvezi az interleaved végrehajtás előnyeit.

Összefűzött végrehajtási többletterhelés

A többletterhelésnek minimálisnak vagy egyáltalán nem létezőnek kell lennie. Az MSTVF-eket már az interleaved végrehajtás bevezetése előtt materializálták, de a különbség az, hogy most már lehetővé tesszük a késleltetett optimalizálást, majd a materializált sorkészlet számosságbecslését használjuk. Mint minden terv, amely változásokat érint, egyes tervek úgy változhatnak, hogy a részfa jobb számossággal rosszabb tervet kapunk az egész lekérdezéshez. A kockázatcsökkentés magában foglalhatja a kompatibilitási szint visszaállítását, vagy a lekérdezési tár használatával kényszerítheti a terv nem visszalépett verzióját.

Szálak közötti végrehajtás és egymást követő végrehajtás

Miután egy egymást átfedő végrehajtási terv gyorsítótárba kerül, a rendszer az első végrehajtás során módosított becslésekkel rendelkező tervet használja a további végrehajtásokhoz, anélkül, hogy újra létre kellene hozni az egymást átfedő végrehajtást.

Az interleaved végrehajtási tevékenység nyomon követése

A használati attribútumok a tényleges lekérdezés-végrehajtási tervben láthatók:

Végrehajtási terv attribútum Description
ContainsInterleavedExecutionCandidates A QueryPlan csomópontra vonatkozik. Ha igaz, az azt jelenti, hogy a terv egymással összefüggő végrehajtási jelölteket tartalmaz.
IsInterleavedExecuted A TvF-csomópont RelOp alatti RuntimeInformation elemének attribútuma. Ha igaz, az azt jelenti, hogy a művelet egy összefűzött végrehajtási művelet részeként valósult meg.

Az interleaved végrehajtási eseményeket a következő kiterjesztett eseményeken keresztül is nyomon követheti:

XEvent Description
interleaved_exec_status Ez az esemény akkor aktiválódik, ha egymással összefüggő végrehajtás történik.
interleaved_exec_stats_update Ez az esemény az interleaved végrehajtás által frissített számosságbecsléseket ismerteti.
Interleaved_exec_disabled_reason Ez az esemény akkor aktiválódik, ha a lehetséges jelölttel rendelkező lekérdezések nem kapják meg az interleaved végrehajtást.

Egy lekérdezést kell végrehajtani, hogy lehetővé tegye az interleaved végrehajtást az MSTVF számosságbecsléseinek módosításához. A becsült végrehajtási terv azonban továbbra is látható, amikor a végrehajtási jelöltek össze vannak fűzve a ContainsInterleavedExecutionCandidates showplan attribútumon keresztül.

Sávos végrehajtási gyorsítótárazás

Ha egy tervet törölnek vagy kiürítenek a gyorsítótárból, a lekérdezések végrehajtásakor újból kompilálnak, ezt követően az interleaved végrehajtás kerül alkalmazásra. Az egymással összefüggő végrehajtást használó OPTION (RECOMPILE) utasítás létrehoz egy új tervet, és nem gyorsítótárazza azt.

Összekapcsolt végrehajtás és lekérdezéstár interoperabilitás

Az interleaved végrehajtást használó tervek rákényszeríthetők. A terv az a verzió, amely a kezdeti végrehajtás alapján javította a számosságbecsléseket.

Az interleaved végrehajtás letiltása a kompatibilitási szint módosítása nélkül

Az interleaved végrehajtás letiltható az adatbázis vagy az utasítás hatókörében, miközben továbbra is fenntartja a 140-es és újabb adatbázis-kompatibilitási szintet. Ha le szeretné tiltani az adatbázisból származó összes lekérdezésvégrehajtás esetében az interleaved végrehajtást, hajtsa végre a következőket az alkalmazandó adatbázis kontextusában:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Ha engedélyezve van, ez a beállítás engedélyezve jelenik meg a sys.database_scoped_configurations. Az adatbázisból származó összes lekérdezésvégrehajtás újraengedélyezéséhez hajtsa végre a következőket a vonatkozó adatbázis kontextusában:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

Az interleaved végrehajtást egy adott lekérdezésnél is letilthatja a DISABLE_INTERLEAVED_EXECUTION_TVFUSE HINT lekérdezési tipp használatával. Például:

SELECT [fo].[Order Key],
       [fo].[Quantity],
       [fol].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
     INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession', '1-01-2013', '10-15-2014') AS [fol]
         ON [fo].[Order Key] = [fol].[Order Key]
        AND [fo].[City Key] = [fol].[City Key]
        AND [fo].[Customer Key] = [fol].[Customer Key]
        AND [fo].[Stock Item Key] = [fol].[Stock Item Key]
        AND [fo].[Order Date Key] = [fol].[Order Date Key]
        AND [fo].[Picked Date Key] = [fol].[Picked Date Key]
        AND [fo].[Salesperson Key] = [fol].[Salesperson Key]
        AND [fo].[Picker Key] = [fol].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

A USE HINT lekérdezési tipp elsőbbséget élvez az adatbázis hatókörébe tartozó konfigurációval vagy nyomkövetési jelző beállítással szemben.

Skaláris felhasználói függvény befűzése

A következőkre vonatkozik: SQL Server (SQL Server 2019 (15.x)), Azure SQL Database

A skaláris UDF automatikusan relációs kifejezésekké alakítja a skaláris UDF-eket . Beágyazza őket a hívó SQL-lekérdezésbe. Ez az átalakítás javítja a skaláris UDF-ek előnyeit kihasználó számítási feladatok teljesítményét. A skaláris UDF-ek beillesztése megkönnyíti a műveletek költségalapú optimalizálását az UDF-eken belül. Az eredmények hatékonyak, halmazorientáltak és párhuzamosak a nem hatékony, iteratív, soros végrehajtási tervek helyett. Ez a funkció alapértelmezés szerint engedélyezve van a 150-es vagy újabb adatbázis-kompatibilitási szinten.

További információ: Skaláris UDF-beillesztés.

Táblaváltozó késleltetett fordítása

A következőkre vonatkozik: SQL Server (SQL Server 2019 (15.x)), Azure SQL Database

A táblaváltozók késleltetett fordítása javítja a terv minőségét és a táblaváltozókra hivatkozó lekérdezések általános teljesítményét. Az optimalizálás és a kezdeti terv összeállítása során ez a funkció a táblaváltozók sorainak tényleges száma alapján propagálja a számosságbecsléseket. Ez a pontos sorszám-információ ezután az alsóbb rétegbeli tervműveletek optimalizálására szolgál.

A táblaváltozó halasztott fordítása esetén a táblaváltozóra hivatkozó utasítás fordítása az utasítás első tényleges végrehajtásáig halasztva lesz. Ez a késleltetett fordítási viselkedés megegyezik az ideiglenes táblák viselkedésével. Ez a változás az eredeti egysoros becslés helyett a tényleges kardinalitás használatát eredményezi.

A táblaváltozó késleltetett fordításának engedélyezéséhez engedélyezze a lekérdezés futtatásakor csatlakoztatott adatbázis 150-es vagy újabb adatbázis-kompatibilitási szintjét.

A táblaváltozó késleltetett fordítása nem módosítja a táblaváltozók egyéb jellemzőit. Ez a funkció például nem ad hozzá oszlopstatisztikákat a táblaváltozókhoz.

A táblaváltozó elhalasztott fordítása nem növeli az újrafordítás gyakoriságát. Inkább áthelyeződik oda, ahol a kezdeti kompilálás történik. Az eredményként kapott gyorsítótárazott végrehajtási terv a kezdeti halasztott fordítási táblázati változó sorainak száma alapján jön létre. Az egymást követő lekérdezések újrahasználják a gyorsítótárazott tervet. A terv újra felhasználható, amíg a terv ki nem kerül, vagy újra nem készül.

A kezdeti terv összeállításához használt táblaváltozós sorok száma egy tipikus értéket jelöl, amely eltérhet a rögzített sorok számának becslésétől. Ha ez eltér, az alsóbb rétegbeli műveletek előnyt élveznek. Előfordulhat, hogy ez a funkció nem javítja a teljesítményt, ha a táblaváltozó sorainak száma jelentősen eltér a végrehajtások között.

A táblaváltozó késleltetett fordításának letiltása a kompatibilitási szint módosítása nélkül

Tiltsa le a táblaváltozó késleltetett fordítását az adatbázis vagy az utasítás hatókörében, miközben továbbra is fenntartja a 150-es és újabb adatbázis-kompatibilitási szintet. Ha le szeretné tiltani a táblaváltozó késleltetett fordítását az adatbázisból származó összes lekérdezés-végrehajtáshoz, hajtsa végre a következő példát az alkalmazandó adatbázis kontextusában:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Ha újra engedélyezni szeretné a táblaváltozó késleltetett fordítását az adatbázisból származó összes lekérdezés-végrehajtáshoz, hajtsa végre a következő példát az alkalmazandó adatbázis kontextusában:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Halasztott táblaváltozó-fordítást is letilthat egy adott lekérdezéshez, ha DISABLE_DEFERRED_COMPILATION_TV a USE HINT lekérdezési tippként rendeli hozzá. Például:

DECLARE @LINEITEMS TABLE (
    L_OrderKey INT NOT NULL,
    L_Quantity INT NOT NULL);

INSERT @LINEITEMS
SELECT L_OrderKey,
       L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
       O_CustKey,
       O_OrderStatus,
       L_QUANTITY
FROM ORDERS, @LINEITEMS
WHERE O_ORDERKEY = L_ORDERKEY
      AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Paraméter érzékenységi terv optimalizálása

A következőkre vonatkozik: Sql Server 2022 (16.x) és újabb verziók Azure SQL DatabaseFelügyelt Azure SQL-példány

A paraméterérzékenységi terv (PSP) optimalizálása az intelligens lekérdezésfeldolgozó szolgáltatáscsalád része. Azt a forgatókönyvet kezeli, amikor egy paraméteres lekérdezés egyetlen gyorsítótárazott terve nem optimális az összes lehetséges bejövő paraméterértékhez. Ilyenek a nemuniform adateloszlások.

Közelítő lekérdezésfeldolgozás

A hozzávetőleges lekérdezésfeldolgozás egy új szolgáltatáscsalád. Olyan nagy adathalmazok összesítése, ahol a válaszkészség kritikusabb, mint az abszolút pontosság. Ilyen például egy COUNT(DISTINCT()) kiszámítása több mint 10 milliárd soron az irányítópulton való megjelenítéshez. Ebben az esetben az abszolút pontosság nem fontos, de a válaszkészség kritikus fontosságú.

Hozzávetőleges darabszám különböző

A következőkre vonatkozik: SQL Server (SQL Server 2019 (15.x)), Azure SQL Database

Az új APPROX_COUNT_DISTINCT aggregátumfüggvény a csoport egyedi nem null értékeinek hozzávetőleges számát adja vissza.

Ez a funkció az SQL Server 2019 -től (15.x) kezdve érhető el, a kompatibilitási szinttől függetlenül.

További információ: APPROX_COUNT_DISTINCT.

Hozzávetőleges percentilis

A következőkre vonatkozik: SQL Server (SQL Server 2022 -től kezdve (16.x)), Azure SQL Database

Ezek az aggregátumfüggvények egy nagy adathalmaz percentiliseit számítják ki elfogadható rangalapú hibahatárokkal, hogy gyors döntéseket hozzanak hozzávetőleges percentilis összesítő függvények használatával.

További információ: APPROX_PERCENTILE_DISC és APPROX_PERCENTILE_CONT

Batch üzemmód a soros tárhelyen

A következőkre vonatkozik: SQL Server (SQL Server 2019 (15.x)), Azure SQL Database

A rowstore-on a Batch üzemmód lehetővé teszi a kötegelt módú végrehajtást elemzési munkaterhelésekhez anélkül, hogy oszlopbeli indexeket kellene használni. Ez a funkció támogatja a kötegelt módban történő végrehajtást, valamint a lemezen tárolt halmok és B-fa indexek bitképszűrőit. A sor tárban a kötegmód lehetővé teszi az összes meglévő kötegmód-kompatibilis operátor támogatását.

Note

A dokumentáció általában a B-fa kifejezést használja az indexekre hivatkozva. A sorkataszterekben az adatbázismotor egy B+ fát implementál. Ez nem vonatkozik az oszlopcentrikus indexekre vagy a memóriaoptimalizált táblák indexére. További információ: SQL Server és Azure SQL index architektúrája és tervezési útmutatója.

Batch mód végrehajtása – áttekintés

Az SQL Server 2012 (11.x) új funkciót vezetett be az elemzési számítási feladatok felgyorsításához: oszlopcentrikus indexek. Az oszlopcentrikus indexek használati esetei és teljesítménye növekedett az SQL Server minden további kiadásában. Az oszlopcentrikus indexek táblákon való létrehozása javíthatja az elemzési számítási feladatok teljesítményét. Azonban két kapcsolódó, de különböző technológiakészlet létezik:

  • Oszlopcentrikus indexek esetén az elemzési lekérdezések csak a szükséges oszlopokban lévő adatokat érik el. Az oszlopcentrikus formátumú laptömörítés is hatékonyabb, mint a hagyományos sorsortár-indexek tömörítése.
  • A kötegelt módú feldolgozással a lekérdezési operátorok hatékonyabban dolgozzák fel az adatokat. Egyszerre sorok kötegével dolgoznak, nem pedig soronként. Számos más méretezhetőségi fejlesztés köteg módú feldolgozáshoz kötődik. A kötegelt módról további információt a Végrehajtási módok alatt talál.

A két funkció együtt dolgozik a bemeneti/kimeneti (I/O) és a CPU-kihasználtság javítása érdekében:

  • Oszlopcentrikus indexek használatával több adat is elfér a memóriában. Ez csökkenti az I/O-számítási feladatot.
  • A batch módú feldolgozás hatékonyabban használja fel a processzort.

A két technológia lehetőség szerint kihasználja egymást. A kötegelt módú aggregátumok például egy oszlop-alapú index vizsgálat részeként értékelhetők ki. A tömörített oszlopcentrikus adatokat futáshosszú kódolással sokkal hatékonyabban dolgozzák fel kötegelt módú illesztésekkel és kötegelt módú aggregálásokkal.

Fontos azonban tisztában lenni azzal, hogy a két funkció független:

  • Sormódú, oszlopcentrikus indexeket használó terveket is lekérhet.
  • Olyan kötegelt módú terveket is lekérhet, amelyek csak soros tároló indexeket használnak.

A két funkció együttes használatakor általában a legjobb eredményt kapja. Az SQL Server 2019 (15.x) előtt az SQL Server lekérdezésoptimalizálója csak azokra a lekérdezésekre alkalmazta a kötegelt feldolgozást, amelyek legalább egy oszlopstore indexet tartalmazó táblát foglalnak magukban.

Előfordulhat, hogy az oszlopcentrikus indexek egyes alkalmazásokhoz nem megfelelőek. Egy alkalmazás más olyan funkciót is használhat, amely nem támogatott oszlopcentrikus indexekkel. A helyben végzett módosítások például nem kompatibilisek az oszlopcentrikus tömörítéssel. Ezért a triggerek nem támogatottak klaszteres oszloptár indexekkel rendelkező táblákban. Ennél is fontosabb, hogy az oszlopcentrikus indexek többletterhelést adnak a DELETE és AZ UPDATE utasításokhoz.

Egyes hibrid tranzakcióelemzési számítási feladatok esetében a tranzakciós számítási feladatok többletterhelése meghaladja az oszlopcentrikus indexek használatából származó előnyöket. Az ilyen forgatókönyvek kihasználhatják a jobb processzorhasználatot, ha csak kötegelt módú feldolgozást alkalmaznak. Ezért a batch-mode-on-rowstore funkció minden lekérdezéshez figyelembe veszi a köteg módot, függetlenül attól, hogy milyen típusú indexek vannak bevonva.

Olyan számítási feladatok, amelyek kihasználhatják a batch mód előnyeit a rowstore-on

A következő számítási feladatok kihasználhatják a kötegelt módot a soros adattárban:

  • A számítási feladat jelentős része elemzési lekérdezésekből áll. Ezek a lekérdezések általában olyan operátorokat használnak, mint például illesztések vagy összesítések, amelyek több százezer sort dolgoznak fel vagy akár ennél is többet.
  • A számítási feladat processzorhoz kötött. Ha a szűk keresztmetszet az I/O, akkor is ajánlott az oszlopalapú indexet használni, ahol lehetséges.
  • Az oszlopcentrikus index létrehozása túl sok többletterhelést okoz a számítási feladat tranzakciós részének. Vagy az oszlopcentrikus index létrehozása nem kivitelezhető, mert az alkalmazás egy olyan funkciótól függ, amely még nem támogatott az oszlopcentrikus indexekkel.

Note

A rowstore Batch üzemmódja csak a processzorhasználat csökkentésével segít. Ha a szűk keresztmetszet az I/O-ra vonatkozik, és az adatok még nem gyorsítótárazva ("hideg" gyorsítótár), a rowstore kötegelt üzemmódja nem javítja a lekérdezések eltelt idejét. Hasonlóképpen, ha nincs elegendő memória a gépen az összes adat gyorsítótárazásához, akkor nem valószínű, hogy javul a teljesítmény.

Milyen változások történnek a batch módban a rowstore-ban?

A rowstore Batch-módjához az adatbázis 150-es kompatibilitási szint szükséges.

Még ha egy lekérdezés nem is fér hozzá oszlopcentrikus indexekkel rendelkező táblákhoz, a lekérdezésfeldolgozó heurisztikus módszerekkel dönti el, hogy a köteg módot érdemes-e figyelembe venni. A heurisztika az alábbi ellenőrzésekből áll:

  1. A táblaméretek, a használt operátorok és a becsült számosságok kezdeti ellenőrzése a bemeneti lekérdezésben.
  2. További ellenőrzőpontok, mivel az optimalizáló új, olcsóbb csomagokat fedez fel a lekérdezéshez. Ha ezek az alternatív tervek nem használják jelentős mértékben a kötegelt módot, az optimalizáló leállítja a kötegelt módú alternatívák felderítését.

Ha a sortárban a kötegelt módot használja, a lekérdezési tervben a tényleges futtatási mód kötegelt mód lesz. A szkennelési operátor kötegelt feldolgozási módot használ a lemezre mentett halmokhoz és a B-fa indexekhez. Ez a köteg módú vizsgálat képes kiértékelni a köteg mód bitképszűrőit. A tervben más kötegelt üzemmódú operátorok is megjelenhetnek. Ilyenek például a kivonat-illesztések, a kivonatalapú összesítések, a rendezések, az ablakösszesítések, a szűrők, az összefűzés és a számítási skaláris operátorok.

Remarks

A lekérdezési csomagok nem mindig használnak köteg módot. A Lekérdezésoptimalizáló úgy dönthet, hogy a tételes mód nem előnyös a lekérdezéshez.

A Lekérdezésoptimalizáló keresési területe megváltozik. Ha tehát sor módú csomagot kap, előfordulhat, hogy az nem ugyanaz, mint az alacsonyabb kompatibilitási szinttel rendelkező csomag. Ha köteg módú csomagot kap, előfordulhat, hogy az nem ugyanaz, mint az oszlopcentrikus indexet tartalmazó csomag.

Az oszlopalapú és a soralapú indexeket kombináló lekérdezések tervei is változhatnak az új kötegelt módú soralapú adatvizsgálat miatt.

A rowstore-vizsgálat új kötegelési módjára jelenleg korlátozások vonatkoznak:

  • Memória alapú OLTP-táblákra, valamint a lemezen lévő halmok és B-fák kivételével egyetlen indexre sem érvényesül.
  • Akkor sem indul el, ha egy nagy objektum (LOB) oszlopot lekérnek vagy szűrnek. Ez a korlátozás a ritka oszlopkészleteket és az XML-oszlopokat is magában foglalja.

Vannak olyan lekérdezések, amelyeket a batch mód még oszlopcentrikus indexekkel sem használ. Ilyenek például a kurzort tartalmazó lekérdezések. Ezek a kizárások a soros tárrendszeren a kötegelt üzemmódra is kiterjednek.

Batch mód konfigurálása rowstore esetén

Az BATCH_MODE_ON_ROWSTOREadatbázis hatókörébe tartozó konfiguráció alapértelmezés szerint BE van kapcsolva.

A sortárhoz kapcsolódó kötegelt módot letilthatja anélkül, hogy módosítaná az adatbázis kompatibilitási szintjét.

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

A kötegelt módot az adatbázis hatókörébe tartozó konfigurációval tilthatja le a rowstore-on. A lekérdezés szintjén azonban továbbra is felülbírálhatja a beállítást a ALLOW_BATCH_MODE lekérdezési tipp használatával. Az alábbi példa lehetővé teszi a kötegelt módot a sortárban, még akkor is, ha az adatbázis-hatókörű konfiguráció letiltja a funkciót:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

A kötegelt módot egy adott lekérdezésnél a sortárolónál is letilthatja a DISALLOW_BATCH_MODE lekérdezési szempont használatával. Lásd a következő példát:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Lekérdezésfeldolgozási visszajelzési funkciók

A lekérdezésfeldolgozási visszajelzési funkciók az intelligens lekérdezésfeldolgozó funkciók családjának részei.

A lekérdezésfeldolgozási visszajelzés egy folyamat, amellyel az SQL Server, az Azure SQL Database és az Azure SQL Managed Instance lekérdezésfeldolgozója a lekérdezés végrehajtására vonatkozó előzményadatokat használja annak eldöntésére, hogy a lekérdezés kaphat-e segítséget a fordítás és a végrehajtás módjának egy vagy több módosításától. A teljesítményadatokat a lekérdezéstárban gyűjtjük össze, és különböző javaslatokat tesz a lekérdezések végrehajtásának javítására. Ha sikeres, a lemez ezen módosításait a memóriában és/vagy a lekérdezéstárban is megőrizzük későbbi használatra. Ha a javaslatok nem eredményeznek megfelelő javulást, a rendszer elveti őket, és a lekérdezés a visszajelzés nélkül is folytatódik.

Arról, hogy mely lekérdezésfeldolgozási visszajelzési funkciók érhetők el az SQL Server különböző kiadásaiban, illetve az Azure SQL Database-ben vagy a felügyelt Azure SQL-példányban, tekintse meg az SQL-adatbázisok intelligens lekérdezésfeldolgozását , vagy az egyes visszajelzési funkciókhoz tartozó alábbi cikkeket.

Memória-hozzáférési visszajelzés

A memóriahasználati visszajelzések hullámokban jelentek meg az SQL Server korábbi fő kiadásaiban.

Batch módú memóriavisszajelzés

A Batch mód memóriahasználati visszajelzésével kapcsolatos információkért látogasson el a Batch mód memóriahasználati visszajelzésére.

A sormód memóriahasználata visszajelzést ad

A sormódú memóriahasználati visszajelzésekről további információt a Sor mód memóriahasználati visszajelzésében talál.

Percentilis és perzisztencia módú memória visszajelzést ad

A percentilis és a perzisztencia mód memória-visszajelzésével kapcsolatos információkért látogasson el a Percentile és Perzisztencia mód memória-visszajelzésére.

A párhuzamosság foka (DOP) visszajelzése

A DOP-visszajelzésről további információt a párhuzamossági fok (DOP) visszajelzésében talál.

Kardinalitásbecslés (CE) visszajelzés

Az CE-visszajelzésről szóló információkért látogasson el a Számosságbecslés (CE) visszajelzés oldalára.

Optimalizált terv kényszerítése a Lekérdezéstár használatával

A Lekérdezéstárral való optimalizált tervkényszerítéssel kapcsolatos információkért látogasson el az Optimalizált terv kényszerítése a Lekérdezéstárral című témakörre.

Kapcsolódó tartalom

  • Last updated on