Számosság becslése (SQL Server)

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

Az SQL Server Query Optimizer egy költségalapú lekérdezésoptimalizáló. Ez azt jelenti, hogy olyan lekérdezésterveket választ ki, amelyek a legalacsonyabb becsült feldolgozási költséggel rendelkeznek. A Lekérdezésoptimalizáló két fő tényező alapján határozza meg a lekérdezésterv végrehajtásának költségét:

• A lekérdezési terv minden szintjén feldolgozott sorok teljes száma, más néven a terv számossága.
• A lekérdezésben használt operátorok által diktált algoritmus költségmodellje.

Az első tényező, a számosság, a második tényező, a költségmodell bemeneti paramétereként működik. Ezért a javított számosság jobban becsült költségeket eredményez, és ennek következményeként gyorsabb végrehajtási terveket.

Az SQL Server számosságbecslése (CE) elsősorban olyan hisztogramokból származik, amelyek indexek vagy statisztikák létrehozásakor jönnek létre manuálisan vagy automatikusan. Az SQL Server néha kényszerinformációkat és a lekérdezések logikai átírását is használja a számosság meghatározásához.

Az alábbi esetekben az SQL Server nem tudja pontosan kiszámítani a számosságokat. Ez pontatlan költségszámításokat okoz, amelyek optimálisnál rosszabb lekérdezési terveket okozhatnak. Ha elkerüli ezeket a szerkezeteket a lekérdezésekben, az javíthatja a lekérdezések teljesítményét. Néha alternatív lekérdezési megfogalmazások vagy más mértékek is lehetségesek, és ezek a következőkre mutatnak:

• Olyan predikátumokkal rendelkező lekérdezések, amelyek összehasonlító operátorokat használnak ugyanazon tábla különböző oszlopai között.
• Az operátorokat használó predikátumokkal rendelkező lekérdezések és az alábbiak bármelyike igaz:
  • Az operátorok mindkét oldalán nincsenek statisztikai adatok az érintett oszlopokról.
  • A statisztikák értékeinek eloszlása nem egységes, de a lekérdezés egy nagyon szelektív értékkészletet keres. Ez a helyzet különösen igaz lehet, ha az operátor nem az egyenlőség (=) operátor.
  • A predikátum a nem egyenlő (!=) összehasonlító operátort vagy a logikai operátort NOT használja.
• Olyan lekérdezések, amelyek az SQL Server bármely beépített függvényét használják, vagy egy skaláris értékű, felhasználó által definiált függvényt, amelynek argumentuma nem állandó érték.
• Olyan lekérdezések, amelyek oszlopokat aritmetikai vagy sztringösszefűző operátorokon keresztül illesztenek össze.
• Olyan változókat összehasonlító lekérdezések, amelyek értékei nem ismertek a lekérdezés fordítása és optimalizálása során.

Ez a cikk bemutatja, hogyan értékelheti és választhatja ki a rendszer számára legmegfelelőbb CE-konfigurációt. A legtöbb rendszer a legújabb CE-t használja, mert ez a legpontosabb. A CE előrejelzi, hogy a lekérdezés hány sort fog visszaadni. A számosság-előrejelzést a Lekérdezésoptimalizáló használja az optimális lekérdezési terv létrehozásához. Pontosabb becslésekkel a Lekérdezésoptimalizáló általában jobb munkát végezhet egy optimálisabb lekérdezési terv létrehozásában.

Előfordulhat, hogy az alkalmazásrendszer rendelkezik egy fontos lekérdezéssel, amelynek tervét a CE-verziók változásai miatt lassabb tervre módosították. A CE-problémák miatt lassabban teljesítő lekérdezések azonosítására szolgáló technikákkal és eszközökkel rendelkezik. Emellett lehetősége van a következő teljesítményproblémák megoldására is.

A CE verziói

1998-ban a CE jelentős frissítése az SQL Server 7.0 része volt, amelynek kompatibilitási szintje 70 volt. A CE-modell ezen verziója négy alapvető feltételezésre van beállítva:

• Függetlenség: A különböző oszlopokon lévő adateloszlások egymástól függetlennek tekinthetők, kivéve, ha korrelációs információk állnak rendelkezésre és használhatók.

• Egységesség: A különböző értékek egyenlően vannak elosztva, és mindegyik azonos gyakorisággal rendelkezik. Pontosabban az egyes hisztogramlépések között a különböző értékek egyenletesen oszlanak el, és minden érték azonos gyakorisággal rendelkezik.

• Adatkezelés (egyszerű): A felhasználók olyan adatokat kérdeznek le, amelyek léteznek. Két tábla közti egyenlőségi illesztés esetén például vegye figyelembe a predikátumok szelektivitását minden bemeneti hisztogramban, mielőtt a hisztogramokat csatlakoztatná az illesztési szelektivitás becsléséhez.

• Belefoglalás: Az olyan szűrő predikátumok esetében, ahol Column = Constantaz állandó ténylegesen létezik a társított oszlophoz. Ha a megfelelő hisztogramlépés nem üres, akkor feltételezve, hogy a lépés egyik különböző értéke megegyezik a predikátum értékével.

  ¹ Olyan sorszám, amely megfelel a predikátumnak.

A későbbi frissítések az SQL Server 2014-zel (12.x) kezdődtek, ami azt jelenti, hogy a kompatibilitási szintek 120-ra vagy újabbra emelkednek. A 120- és újabb szintek CE-frissítései olyan frissített feltételezéseket és algoritmusokat tartalmaznak, amelyek jól működnek a modern adattárházakban és az OLTP számítási feladatokban. A CE 70 feltételezései alapján a ce 120-tól kezdődően a következő modellfeltevések módosultak:

• A függetlenségkorrelációvá válik: A különböző oszlopértékek kombinációja nem feltétlenül független. Ez a valós idejű adatlekérdezéshez hasonlíthat.
• Az egyszerű elszigetelésalapszintű elszigeteléssé válik: a felhasználók lekérdezhetik a nem létező adatokat. Két tábla közötti egyenlőségi illesztéshez például az alaptáblák hisztogramjaival megbecsüljük az illesztési szelektivitást, majd a predikátumok szelektivitásának tényezőjét.

A Ce-verzió értékelése a Lekérdezéstár használatával

Az SQL Server 2016 -tól (13.x) kezdődően a Lekérdezéstár hasznos eszköz a lekérdezések teljesítményének vizsgálatához. Ha a Lekérdezéstár engedélyezve van, akkor is elkezdi nyomon követni a lekérdezés teljesítményét, még akkor is, ha a végrehajtási tervek módosulnak. A lekérdezéstár monitorozása magas költségű vagy regressziós lekérdezési teljesítmény érdekében. További információ: Teljesítmény monitorozása a Lekérdezéstár használatával.

Ha az SQL Serverre való frissítésre készül, vagy bármely SQL Server-platform adatbáziskompatibilitási szintjét támogatja, fontolja meg az adatbázisok frissítését a Lekérdezéshangolási segéd használatával, amely két különböző kompatibilitási szint lekérdezési teljesítményének összehasonlításához nyújt segítséget.

Important

Győződjön meg arról, hogy a lekérdezéstár megfelelően van konfigurálva az adatbázishoz és a számítási feladathoz. További információ: Ajánlott eljárások a számítási feladatok lekérdezéstárral való monitorozásához.

Bővített események használata a CE-verzió értékeléséhez

A számosságbecslési folyamat nyomon követésének másik lehetősége a kiterjesztett, elnevezett query_optimizer_estimate_cardinalityesemény használata. Az alábbi Transact-SQL kódminta az SQL Serveren fut. .xel-fájlt ír a C:\Temp\-ba (bár módosíthatja az elérési útvonalat). Amikor megnyitja a .xel fájlt a Management Studióban, annak részletes információi felhasználóbarát módon jelennek meg.

DROP EVENT SESSION Test_the_CE_qoec_1 ON SERVER;
go

CREATE EVENT SESSION Test_the_CE_qoec_1
ON SERVER
ADD EVENT sqlserver.query_optimizer_estimate_cardinality
 (
 ACTION (sqlserver.sql_text)
  WHERE (
  sql_text LIKE '%yourTable%'
  and sql_text LIKE '%SUM(%'
  )
 )
ADD TARGET package0.asynchronous_file_target
 (SET
  filename = 'c:\temp\xe_qoec_1.xel',
  metadatafile = 'c:\temp\xe_qoec_1.xem'
 );
GO

ALTER EVENT SESSION Test_the_CE_qoec_1
ON SERVER
STATE = START;  --STOP;
GO

Note

Az esemény sqlserver.query_optimizer_estimate_cardinality nem érhető el az Azure SQL Database-hez.

Az SQL Database-hez szabott kiterjesztett eseményekről további információt az SQL Database kiterjesztett eseményei című témakörben talál.

A CE-verzió értékelésének lépései

A következő lépésekkel felmérheti, hogy a legfontosabb lekérdezések rosszabbul teljesítenek-e a legújabb CE-ben. A lépések némelyikét egy előző szakaszban bemutatott kódminta futtatásával hajtjuk végre.

1. Nyissa meg az SQL Server Management Studiót (SSMS). Győződjön meg arról, hogy az SQL Server-adatbázis a legmagasabb rendelkezésre álló kompatibilitási szintre van beállítva.

2. Hajtsa végre az alábbi előzetes lépéseket:

   1. Nyissa meg az SQL Server Management Studiót (SSMS).

   2. Futtassa a Transact-SQL parancsot annak érdekében, hogy az SQL Server adatbázisa a legmagasabb kompatibilitási szintre legyen beállítva.

   3. Győződjön meg arról, hogy az adatbázis konfigurációja LEGACY_CARDINALITY_ESTIMATION be van kapcsolva OFF.

   4. Törölje a lekérdezéstárat. Az adatbázisban győződjön meg arról, hogy a Lekérdezéstár be van kapcsolva.

   5. Futtassa a parancsot: SET NOCOUNT OFF;

3. Futtassa a parancsot: SET STATISTICS XML ON;

4. Hajtsa végre a fontos lekérdezést.

5. Az Eredmények panel Üzenetek lapján jegyezze fel az érintett sorok tényleges számát.

6. Az Eredmények lap eredménypanelén kattintson duplán arra a cellára, amely XML formátumban tartalmazza a statisztikákat. Megjelenik egy grafikus lekérdezési terv.

7. Kattintson a jobb gombbal a grafikus lekérdezési terv első mezőjére, majd válassza a Tulajdonságok lehetőséget.

8. Egy másik konfigurációval való későbbi összehasonlításhoz jegyezze fel az alábbi tulajdonságok értékeit:

   • CardinalityEstimationModelVersion.

   • Sorok becsült száma.

   • Becsült I/O-költség és számos hasonló becsült tulajdonság, amelyek a sorszám-előrejelzések helyett a tényleges teljesítményt foglalják magukban.

   • Logikai művelet és fizikai művelet. A párhuzamosság jó érték.

   • Tényleges végrehajtási mód. A Batch jó érték, jobb, mint a Row.

9. Hasonlítsa össze a sorok becsült számát a sorok tényleges számával. Pontatlan a CE 1%-kal (magasabb vagy alacsonyabb) vagy 10%-kal?

10. Futtatás: SET STATISTICS XML OFF;

11. Futtassa a Transact-SQL parancsot az adatbázis kompatibilitási szintjének csökkentéséhez egy szinttel (például 130-ról 120-ra).

12. Futtassa újra az összes nem kezdeti lépést.

13. Hasonlítsa össze a két futtatás CE-tulajdonságértékeit.

    • Kisebb a pontatlanság aránya a legújabb CE alatt, mint a régebbi CE alatt?

14. Végül hasonlítsa össze a két futtatás különböző teljesítménytulajdonság-értékeit.

    • A lekérdezés eltérő tervet használt a két eltérő CE-becslés alapján?

    • Lassabban futott a lekérdezés a legújabb CE alatt?

    • Hacsak a lekérdezése nem fut jobban egy másik tervvel a régebbi CE alatt, szinte biztosan a legújabb CE-t szeretné használni.

    • Ha azonban a lekérdezés gyorsabb csomaggal fut a régebbi CE alatt, fontolja meg a rendszer kényszerítését a gyorsabb csomag használatára, és hagyja figyelmen kívül a CE-t. Így mindenhez a legújabb CE-t használhatja, miközben a gyorsabb tervet a ritka esetekre megtarthatja.

A legjobb lekérdezési terv aktiválása

Tegyük fel, hogy a CE 120 vagy újabb verzióval a lekérdezéshez kevésbé hatékony lekérdezési terv jön létre. Az alábbiakban néhány lehetőséget kell aktiválnia a jobb tervnek, amely a legnagyobb hatókörtől a legkisebbig van rendezve:

• Az adatbázis kompatibilitási szintjét a legújabb elérhetőnél alacsonyabb értékre állíthatja a teljes adatbázis esetében.

  • Például a 110-es vagy annál alacsonyabb kompatibilitási szint beállítása aktiválja a CE 70-et, de az összes lekérdezést az előző CE-modellhez teszi függővé.

  • Emellett az alacsonyabb kompatibilitási szint beállítása a legújabb verziók lekérdezésoptimalizálójának számos fejlesztését is elmulasztja, és az adatbázison végzett összes lekérdezésre hatással van.

• LEGACY_CARDINALITY_ESTIMATION Használhatja az adatbázis-hatókörű konfigurációs lehetőséget, hogy a teljes adatbázis a régebbi CE-t használja, miközben megtartja a lekérdezésoptimalizáló egyéb fejlesztéseit.

• Használhatja a LEGACY_CARDINALITY_ESTIMATION lekérdezési tippeket arra, hogy egy adott lekérdezés a régebbi CE-t alkalmazza, miközben a lekérdezésoptimalizáló egyéb fejlesztései megmaradnak.

• A Lekérdezéstár tipp funkcióval kikényszeríthető LEGACY_CARDINALITY_ESTIMATION , hogy egyetlen lekérdezés használja a régebbi CE-t a lekérdezés módosítása nélkül.

• Kényszerítsen egy másik tervet a Query Store segítségével.

Adatbázis-kompatibilitási szint

Az alter DATABASE (Transact-SQL) kompatibilitási szintjének alábbi Transact-SQL kódjának használatával biztosíthatja, hogy az adatbázis egy adott szinten legyen.

Important

Az SQL Server és az Azure SQL Database adatbázismotor-verziószámai nem hasonlíthatók össze egymással, és inkább belső buildszámok ezekhez a különálló termékekhez. Az Azure SQL Server adatbázismotorja ugyanazon a kódbázison alapul, mint az SQL Server adatbázismotorja. A legfontosabb, hogy az Azure SQL Database adatbázismotorja mindig a legújabb SQL-adatbázismotor-bitekkel rendelkezik. Az Azure SQL Database 12-es verziója újabb, mint az SQL Server 15-ös verziója. 2019 novemberétől az Azure SQL Database-ben az alapértelmezett kompatibilitási szint az újonnan létrehozott adatbázisok esetében 150. A Microsoft nem frissíti a meglévő adatbázisok adatbázis-kompatibilitási szintjét. Ezt az ügyfelek saját belátásuk szerint tehetik meg.

SELECT ServerProperty('ProductVersion');
GO

SELECT d.name, d.compatibility_level
FROM sys.databases AS d
WHERE d.name = 'yourDatabase';
GO

Az alacsonyabb kompatibilitási szinteken futó, már meglévő adatbázisok esetében, ha az alkalmazásnak nem kell olyan fejlesztéseket használnia, amelyek csak magasabb adatbázis-kompatibilitási szinten érhetők el, a korábbi adatbázis-kompatibilitási szint fenntartása érvényes módszer. Ha új fejlesztési munkát szeretne végezni, vagy ha egy meglévő alkalmazáshoz olyan új funkciókra van szükség, mint például az intelligens lekérdezésfeldolgozás az SQL-adatbázisokban, valamint néhány új Transact-SQL-t, az adatbázis kompatibilitási szintjét a legújabb elérhetőre szeretné frissíteni. További információ: Kompatibilitási szintek és adatbázismotor-frissítések.

Caution

Az adatbázis kompatibilitási szintjének módosítása előtt tekintse át az ALTER DATABASE (Transact-SQL) kompatibilitási szintjét.

ALTER DATABASE <yourDatabase>
SET COMPATIBILITY_LEVEL = 150;
GO

A 120-es vagy újabb kompatibilitási szinten beállított SQL Server-adatbázisok esetében a 9481-es nyomkövetési jelző aktiválása kényszeríti a rendszert a CE 70-es verziójának használatára.

Örökölt számosságbecslő

A 120-es vagy újabb kompatibilitási szinten beállított SQL Server-adatbázisok esetében az örökölt számosságbecslő (CE 70-es verzió) az ADATBÁZIS szintjén aktiválható az ALTER DATABASE SCOPED CONFIGURATION használatával.

ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO

SELECT name, value
FROM sys.database_scoped_configurations
WHERE name = 'LEGACY_CARDINALITY_ESTIMATION';
GO

Lekérdezés módosítása a tipp használatára

Az SQL Server 2016 (13.x) SP1-től kezdve módosítsa a lekérdezést a lekérdezési tippUSE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION') használatára.

SELECT CustomerId, OrderAddedDate
FROM OrderTable
WHERE OrderAddedDate >= '2016-05-01'
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Lekérdezéstár-tipp beállítása

A lekérdezések a lekérdezés módosítása nélkül kényszeríthetők az örökölt számosságbecslő használatára a Lekérdezéstár-tippek használatával.

1. Azonosítsa a lekérdezést a sys.query_store_query_text és sys.query_store_query Lekérdezéstár katalógusnézetekben. Például keressen egy végrehajtott lekérdezést szövegtöredék szerint:

   SELECT q.query_id, qt.query_sql_text
   FROM sys.query_store_query_text qt
   INNER JOIN sys.query_store_query q ON
   qt.query_text_id = q.query_text_id
   WHERE query_sql_text like N'%ORDER BY ListingPrice DESC%'
   AND query_sql_text not like N'%query_store%';
   

2. Az alábbi példa egy Lekérdezéstár-tippet alkalmaz, hogy az örökölt számosság-becslőt query_id 39-re kényszerítse a lekérdezés módosítása nélkül.

   EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(USE HINT(''FORCE_LEGACY_CARDINALITY_ESTIMATION''))';
   

Note

További információ: Lekérdezéstár tippek (előzetes verzió). Ez a funkció jelenleg csak az Azure SQL Database-ben érhető el.

Egy adott lekérdezési terv kényszerítéséről

A legjobb ellenőrzés érdekében kényszerítheti a rendszert a CE 70-ben a tesztelés során létrehozott terv használatára. Az előnyben részesített csomag rögzítése után beállíthatja, hogy a teljes adatbázis a legújabb kompatibilitási szintet és CE-t használja. A lehetőség a következő lépésben lesz kidolgozva.

A Lekérdezéstár különböző módokon kényszerítheti a rendszert egy adott lekérdezési terv használatára:

• Hajtsa végre sys.sp_query_store_force_plan.

• Az SQL Server Management Studióban (SSMS) bontsa ki a Lekérdezéstár csomópontot, kattintson a jobb gombbal az erőforrás-fogyasztó csomópontok tetejére, majd válassza a Top Resource Consuming Nodes (Erőforrás-fogyasztó csomópontok megtekintése) lehetőséget. A kijelzőn a Force Plan és a Unforce Plan feliratú gombok láthatók.

A lekérdezéstárról további információt a Teljesítmény monitorozása a Lekérdezéstár használatával című témakörben talál.

Állandó összecsukás és kifejezésértékelés a számosság becslése során

Az adatbázismotor korai kiértékel néhány állandó kifejezést a lekérdezési teljesítmény javítása érdekében. Ezt nevezik állandó hajtogatásnak. Az állandó egy Transact-SQL konstans, például 3, 'ABC', '2005-12-31', 1.0e3vagy 0x12345678. További információ: Állandó összecsukás.

Ezen kívül a lekérdezésoptimalizáló optimalizálás során a lekérdezésoptimalizáló részét képező eredményhalmaz-méretező (számosság) kiértékeli azokat a kifejezéseket is, amelyek nem állandó módon vannak összehajtva, de amelyek argumentumai a fordításkor ismertek, függetlenül attól, hogy az argumentumok paraméterek vagy állandók. További információ: Kifejezésértékelés.

Ajánlott eljárások: Konstans összevonás és fordítás idejű kifejezések kiértékelése optimális lekérdezési tervek létrehozásához

Annak érdekében, hogy optimális lekérdezési terveket hozzon létre, a legjobb, ha lekérdezéseket, tárolt eljárásokat és kötegeket tervez, hogy a Lekérdezésoptimalizáló pontosan meg tudja becsülni a lekérdezés feltételeinek választóképességét az adateloszlási statisztikák alapján. Ellenkező esetben a lekérdezésoptimalizálónak alapértelmezett becslést kell használnia a szelektivitás becsléséhez.

Annak érdekében, hogy a Lekérdezésoptimalizáló számosságbecslője jó becsléseket biztosítson, először győződjön meg arról, hogy az adatbázis és AUTO_CREATE_STATISTICS az AUTO_UPDATE_STATISTICS adatbázis SET beállításai ON (az alapértelmezett beállítás), vagy manuálisan hozta létre a lekérdezési feltételben hivatkozott összes oszlop statisztikáit. Ezután a lekérdezések feltételeinek tervezésekor tegye a következőket, ha lehetséges:

• Kerülje a helyi változók használatát a lekérdezésekben. Ehelyett használjon paramétereket, literálokat vagy kifejezéseket a lekérdezésben.

• A paramétert tartalmazó lekérdezésekben beágyazott operátorok és függvények használatát korlátozzuk azokra, amelyek fel vannak sorolva a Számosságbecslés futásidejű kifejezés-kiértékelése területen.

• Győződjön meg arról, hogy a lekérdezés feltételében szereplő konstans-csak kifejezések konstansan összecsukhatók, vagy a fordítási időpontban kiértékelhetők.

• Ha egy lekérdezésben használandó kifejezés kiértékeléséhez helyi változót kell használnia, fontolja meg a lekérdezésen kívüli hatókör kiértékelését. Hasznos lehet például az alábbi lehetőségek egyikének végrehajtása:

  • Adja át a változó értékét egy tárolt eljárásnak, amely tartalmazza a kiértékelni kívánt lekérdezést, és a lekérdezés helyi változó helyett használja az eljárásparamétert.

  • Hozzon létre egy olyan sztringet, amely részben a helyi változó értékén alapuló lekérdezést tartalmaz, majd dinamikus SQL (EXEC vagy lehetőleg sp_executesql) használatával hajtsa végre a sztringet.

  • Paraméterezheti a lekérdezést, és végrehajthatja a lekérdezés használatával sp_executesql, majd adja át paraméterként a változó értékét a lekérdezésnek.

Példák a CE-fejlesztésekre

Ez a szakasz olyan példa lekérdezéseket mutat be, amelyek a CE-ben a legutóbbi kiadásokban implementált fejlesztések előnyeit élvezik. Ezek olyan háttérinformációk, amelyek nem kérnek konkrét műveletet az Ön részéről.

Az A. CE-példa megérti, hogy a maximális érték magasabb lehet, mint amikor utoljára gyűjtötték a statisztikákat

Tegyük fel , hogy a statisztikai adatok utoljára akkor lettek összegyűjtve OrderTable2016-04-30, amikor a maximális OrderAddedDate érték volt 2016-04-30. A CE 120 (és a fenti verzió) tisztában van azzal, hogy a OrderTable adatokkal rendelkező oszlopokban a statisztikák által rögzített maximális értéknél nagyobb értékek lehetnek. Ez a megértés javítja Transact-SQL utasítások lekérdezési tervét SELECT , például az alábbiakat.

SELECT CustomerId, OrderAddedDate
FROM OrderTable
WHERE OrderAddedDate >= '2016-05-01';

A B. CE-példa megérti, hogy az ugyanazon a táblán lévő szűrt predikátumok gyakran korrelálnak

Az alábbiakban SELECT szűrt predikátumokat ModelModelVariantés . Intuitív módon megértjük, hogy amikor Model "Xbox", akkor van rá esély, hogy a ModelVariant a "One", mivel az Xboxnak van egy One nevű változata.

A CE 120-tól kezdve az SQL Server érzékeli, hogy lehetséges korreláció lehet az ugyanazon a táblán lévő Model és ModelVariant oszlopok között. A CE pontosabb becslést készít arról, hogy a lekérdezés hány sort ad vissza, és a lekérdezésoptimalizáló optimálisabb tervet hoz létre.

SELECT Model, Purchase_Price
FROM dbo.Hardware
WHERE Model = 'Xbox' AND
ModelVariant = 'Series X';

A C. CE példa már nem feltételez korrelációt a különböző táblákból származó szűrt predikátumok között

A modern számítási feladatokra és a tényleges üzleti adatokra vonatkozó átfogó új kutatások azt mutatják, hogy a különböző táblák szűrőinek predikátumai általában nem egymással korrelálnak. A következő lekérdezésben a CE feltételezi, hogy nincs korreláció s.type és r.date között. Ezért a CE alacsonyabb becslést készít a visszaadott sorok számáról.

SELECT s.ticket, s.customer, r.store
FROM dbo.Sales AS s
CROSS JOIN dbo.Returns AS r
WHERE s.ticket = r.ticket AND
s.type = 'toy' AND
r.date = '2016-05-11';

Kapcsolódó tartalom

• számosságbecslési (CE) visszajelzési
• Monitorozás és teljesítmény optimalizálás
• Lekérdezéstervek optimalizálása az SQL Server 2014 számosságbecslőjével
• Lekérdezési tippek (Transact-SQL)
• A HINT lekérdezési tippjeinek használata
• Adatbázisok frissítése a Lekérdezéshangolási segéd használatával
• A teljesítmény figyelése a Lekérdezéstár segítségével
• lekérdezésfeldolgozási architektúra útmutatója
• Lekérdezéstár útmutatások
• intelligens lekérdezésfeldolgozás SQL-adatbázisokban
• Nyomkövetési jelzők beállítása a DBCC TRACEON használatával (Transact-SQL)
• sys.query_store_query_hints