statisztika

A következőkre vonatkozik:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics SQL-adatbázis a Microsoft Fabricben

A Lekérdezésoptimalizáló statisztikák használatával olyan lekérdezési terveket hoz létre, amelyek javítják a lekérdezés teljesítményét. A legtöbb lekérdezés esetében a Lekérdezésoptimalizáló már létrehozza a megfelelő statisztikákat egy kiváló minőségű lekérdezési tervhez; bizonyos esetekben további statisztikákat kell létrehoznia, vagy módosítania kell a lekérdezéstervet a legjobb eredmények érdekében. Ez a cikk a statisztikai fogalmakat ismerteti, és útmutatást nyújt a lekérdezésoptimalizálási statisztikák hatékony használatához.

Összetevők és fogalmak

statisztika

A lekérdezésoptimalizálás statisztikái olyan bináris nagy objektumok (BLOB-k), amelyek statisztikai adatokat tartalmaznak az értékek eloszlásáról egy vagy több oszlopban egy tábla vagy indexelt nézetben. A Lekérdezésoptimalizáló ezeket a statisztikákat használja a lekérdezés eredményében szereplő számosság, azaz a sorok számának becslésére. Ezek a számosságbecslések lehetővé teszik, hogy a Lekérdezésoptimalizáló kiváló minőségű lekérdezéstervet hozzon létre. Például a predikátumoktól függően a Lekérdezésoptimalizáló számosságbecslésekkel választhatja ki az indexkeresési operátort az erőforrás-igényesebb indexvizsgálati operátor helyett, ha ez javítja a lekérdezés teljesítményét.

Minden statisztikai objektum egy vagy több táblaoszlop listájában jön létre, és tartalmaz egy hisztogramot , amely az első oszlop értékeinek eloszlását jeleníti meg. A statisztikai objektumok több oszlopon is tárolnak statisztikai adatokat az oszlopok közötti értékek korrelációjáról. Ezek a korrelációs statisztikák vagy sűrűségek az oszlopértékek különböző sorainak számából származnak.

Histogram

A hisztogram az adathalmaz minden egyes különböző értékének előfordulási gyakoriságát méri. A Lekérdezésoptimalizáló kiszámítja a statisztikai objektum első kulcsoszlopában lévő oszlopértékek hisztogramját, kiválasztja az oszlopértékeket a sorok statisztikai mintavételezésével vagy a tábla vagy nézet összes sorának teljes vizsgálatával. Ha a hisztogram egy mintául szolgáló sorkészletből jön létre, a sorok számának és a különböző értékek számának tárolt összegei becslések, és nem kell egész egész számoknak lenniük.

Note

Az SQL Server hisztogramjai csak egyetlen oszlophoz vannak létrehozva– ez a statisztikai objektum kulcsoszlopainak első oszlopa.

A hisztogram létrehozásához a Lekérdezésoptimalizáló rendezi az oszlopértékeket, kiszámítja az egyes oszlopértékeknek megfelelő értékek számát, majd az oszlopértékeket legfeljebb 200 összefüggő hisztogramlépésre összesíti. Minden hisztogram lépés tartalmaz egy oszlopértéktartományt, amelyet egy felső kötött oszlopérték követ. A tartomány magában foglalja a határértékek közötti összes lehetséges oszlopértéket, kivéve magukat a határértékeket. A rendezett oszlopértékek közül a legalacsonyabb az első hisztogramlépés felső határértéke.

Részletesebben az SQL Server három lépésben hozza létre a hisztogramot az oszlopértékek rendezett készletéből:

Hisztogram inicializálása: Az első lépésben egy értéksorozatot dolgozunk fel a rendezett készlet elejétől kezdve, és legfeljebb 200 range_high_key, equal_rows, range_rows és distinct_range_rows értéket gyűjtünk (a range_rows és a distinct_range_rows értéke ebben a lépésben mindig nulla). Az első lépés akkor fejeződik be, ha az összes bemenet kimerült, vagy ha 200 érték található.
Keresés gyűjtőegyesítéssel: A statisztikai kulcs kezdő oszlopának minden további értéke a második lépésben, rendezett sorrendben lesz feldolgozva; minden egymást követő érték hozzáadódik az utolsó tartományhoz, vagy létrejön egy új tartomány a végén (ez azért lehetséges, mert a bemeneti értékek rendezve vannak). Ha új tartományt hoz létre, akkor a meglévő, szomszédos tartományok egy párja egyetlen tartományba lesz összecsukva. Ez a tartománypár az információvesztés minimalizálása érdekében van kiválasztva. Ez a módszer egy maximális különbségi algoritmussal minimalizálja a hisztogram lépéseinek számát, miközben maximalizálja a határértékek közötti különbséget. Az összecsukási tartományok utáni lépések száma ebben a lépésben 200 marad.
Hisztogram-konszolidálás: A harmadik lépésben több tartomány összecsukható, ha jelentős mennyiségű információ nem vesz el. A hisztogram lépéseinek száma kisebb lehet, mint a különböző értékek száma, még a 200-nál kevesebb határponttal rendelkező oszlopok esetében is. Ezért még akkor is, ha az oszlop több mint 200 egyedi értékkel rendelkezik, a hisztogram legfeljebb 200 lépésből állhat. A csak egyedi értékeket tartalmazó oszlopok esetében az összevont hisztogram legalább három lépésből áll.

Note

Ha a hisztogram a fullscan helyett egy mintával lett létrehozva, akkor a equal_rows, range_rows, distinct_range_rows és average_range_rows értékeit megbecsüljük, ezért nem kell egész egész számoknak lenniük.

Az alábbi ábrán egy hat lépésből áll a hisztogram. Az első felső határérték bal oldalán található terület az első lépés.

Diagram a hisztogram mintául szolgáló oszlopértékekből való kiszámításának módjáról.

Az előző példában szereplő összes hisztogram lépésnél:

A félkövér vonal a felső határértéket (range_high_key) és az előfordulások számát (equal_rows) jelöli.
A range_high_key egyszínű területe az oszlopértékek tartományát és az egyes oszlopértékek előfordulásának átlagos számát (average_range_rows) jelöli. Az első hisztogram lépésaverage_range_rows értéke mindig 0.
A pontozott vonalak a tartomány különböző értékeinek teljes számának (distinct_range_rows) és a tartomány értékeinek teljes számának (range_rows) becsléséhez használt mintaértékeket jelölik. A Lekérdezésoptimalizáló range_rows és distinct_range_rows használ a average_range_rows kiszámításához, és nem tárolja a mintául szolgáló értékeket.

Sűrűségvektor

A sűrűség egy adott oszlopban vagy oszlopkombinációban lévő duplikált értékek számának információja, és 1/(különböző értékek száma) alapján van kiszámítva. A Lekérdezésoptimalizáló sűrűségek használatával növeli a számosságbecsléseket az olyan lekérdezések esetében, amelyek ugyanazon tábla vagy indexelt nézetben több oszlopot ad vissza. A sűrűség csökkenésével az érték szelektivitása nő. Az autókat ábrázoló táblázatban például sok autó ugyanazzal a gyártóval rendelkezik, de mindegyik autó egyedi járműazonosítóval (VIN) rendelkezik. A VIN indexe szelektívebb, mint a gyártó indexe, mivel a VIN sűrűsége alacsonyabb, mint a gyártóé.

Note

A gyakoriság a statisztikai objektum első kulcsoszlopában található egyes különböző értékek előfordulására vonatkozó információ, és a rendszer a következőképpen számítja ki row count * density: . Az egyedi értékeket tartalmazó oszlopokban legfeljebb 1 gyakoriság található.

A sűrűségvektor egy sűrűséget tartalmaz a statisztikai objektum egyes oszlopelőtagjaihoz. Ha például egy statisztikai objektumban a kulcsoszlopok CustomerId, ItemId és Price, a sűrűség kiszámítása az alábbi oszlopelőtagok mindegyikén történik.

Oszlopelőtag	Sűrűség számítása:
(`CustomerId`)	A `CustomerId` egyező értékeket tartalmazó sorok
(`CustomerId`, `ItemId`)	A `CustomerId` és `ItemId` egyező értékekkel rendelkező sorok
(`CustomerId`, `ItemId`, `Price`)	A `CustomerId`, `ItemId`és `Price` egyező értékekkel rendelkező sorok

Szűrt statisztikák

A szűrt statisztikák javíthatják a lekérdezési teljesítményt a jól definiált adathalmazokból kiválasztott lekérdezések esetében. A szűrt statisztikák egy szűrő predikátum használatával választják ki a statisztikákban szereplő adatok részhalmazát. A jól megtervezett szűrt statisztikák a teljes táblázatos statisztikákhoz képest javíthatják a lekérdezések végrehajtási tervét. A szűrő predikátumával kapcsolatos további információkért lásd: CREATE STATISTICS. A szűrt statisztikák létrehozásának időpontjával kapcsolatos további információkért tekintse meg a jelen cikk "Mikor hozzon létre statisztikákat " című szakaszát.

Statisztikai beállítások

Vannak olyan lehetőségek, amelyek befolyásolják a statisztikák létrehozását és frissítését. Ezek a beállítások csak az adatbázis szintjén konfigurálhatók.

AUTO_CREATE_STATISTICS lehetőség

Ha az automatikus statisztikai létrehozási lehetőség AUTO_CREATE_STATISTICS be van kapcsolva, a Lekérdezésoptimalizáló szükség szerint statisztikákat hoz létre a lekérdezési predikátum egyes oszlopaihoz a lekérdezésterv számosságbecsléseinek javítása érdekében. Ezek az egyoszlopos statisztikák olyan oszlopokon jönnek létre, amelyek még nem rendelkeznek hisztogrammal egy meglévő statisztikai objektumban. A AUTO_CREATE_STATISTICS beállítás nem határozza meg, hogy létrejönnek-e statisztikák az indexekhez. Ez a beállítás nem hoz létre szűrt statisztikákat sem. Szigorúan a teljes tábla egyoszlopos statisztikáira vonatkozik.

Amikor a Lekérdezésoptimalizáló a beállítás használatával AUTO_CREATE_STATISTICS statisztikákat hoz létre, a statisztika neve a következővel _WAkezdődik: . Az alábbi lekérdezéssel megállapíthatja, hogy a Lekérdezésoptimalizáló létrehozott-e statisztikai adatokat egy lekérdezési predikátumoszlophoz.

SELECT OBJECT_NAME(s.object_id) AS object_name,
    COL_NAME(sc.object_id, sc.column_id) AS column_name,
    s.name AS statistics_name
FROM sys.stats AS s
    INNER JOIN sys.stats_columns AS sc
        ON s.stats_id = sc.stats_id
        AND s.object_id = sc.object_id
WHERE s.name LIKE '_WA%'
ORDER BY s.name;

AUTO_UPDATE_STATISTICS lehetőség

Ha az automatikus frissítési statisztikai beállítás AUTO_UPDATE_STATISTICS be van kapcsolva, a Lekérdezésoptimalizáló meghatározza, hogy mikor lehetnek elavultak a statisztikák, majd frissíti őket, amikor egy lekérdezés használja őket. Ezt a műveletet statisztikai újrafordításnak is nevezik. A statisztikák elavulttá válnak, miután a beszúrási, frissítési, törlési vagy egyesítési műveletek módosításai megváltoztatták az adateloszlást a táblázat vagy az indexelt nézetben. A Lekérdezésoptimalizáló úgy határozza meg, hogy a statisztikák mikor lehetnek elavultak, ha megszámolja a legutóbbi statisztikák frissítése óta végrehajtott sormódosítások számát, és összehasonlítja a sormódosítások számát a küszöbértékekkel. A küszöbérték a tábla kardinalitásán alapul, amely a tábla vagy indexelt nézetben lévő sorok számaként határozható meg.

A statisztikák sormódosítások alapján elavultként való megjelölése akkor is megtörténik, ha a AUTO_UPDATE_STATISTICS beállítás ki van kapcsolva. Ha a AUTO_UPDATE_STATISTICS beállítás ki van kapcsolva, a statisztikák nem frissülnek, még akkor sem, ha elavultként vannak megjelölve. A tervek továbbra is a elavult statisztikai objektumokat használják. Az AUTO_UPDATE_STATISTICS OFF értékre állítása kevésbé optimális lekérdezési terveket és gyengébb lekérdezési teljesítményt okozhat. Ajánlott bekapcsolni a AUTO_UPDATE STATISTICS beállítást.

Az SQL Server 2014-ig (12.x) az adatbázismotor egy újrafordítási küszöbértéket használ a tábla sorainak száma vagy az indexelt nézet alapján a statisztikák kiértékelésének időpontjában. A küszöbérték attól eltérő, hogy egy tábla ideiglenes vagy állandó.

Táblázat típusa	Tábla számossága (n)	Újrafordítási küszöbérték (# módosítások)
Temporary	n< 6	6
Temporary	6 <= n<= 500	500
Permanent	N<= 500	500
Ideiglenes vagy állandó	n> 500	500 + (0,20 * n)

Ha például a táblázat 20 ezer sort tartalmaz, akkor a számítás 500 + (0.2 * 20,000) = 4,500 és a statisztikák 4500 módosítást követően frissülnek.

Az SQL Server 2016 -tól kezdve (13.x) és az adatbázis-kompatibilitási szint 130-tól kezdve az adatbázismotor egy csökkenő, dinamikus statisztikai újrafordítási küszöbértéket is használ, amely a statisztikai adatok kiértékelésekor a tábla számosságának megfelelően módosul. Ezzel a változással a nagyméretű táblák statisztikái gyakrabban frissülnek. Ha azonban egy adatbázis kompatibilitási szintje 130 alatt van, akkor az SQL Server 2014 (12.x) küszöbértékei érvényesek.

Táblázat típusa	Tábla számossága (n)	Újrafordítási küszöbérték (# módosítások)
Temporary	`n < 6`	6
Temporary	`6 <= n <= 500`	500
Permanent	`n <= 500`	500
Ideiglenes vagy állandó	`n > 500`	`MIN ( 500 + (0.20 * n), SQRT(1,000 * n) )`

Ha például a táblázat 2 millió sort tartalmaz, akkor a számítás az 500 + (0.20 * 2,000,000) = 400,500 és SQRT(1,000 * 2,000,000) = 44,721 minimuma. Ez azt jelenti, hogy a statisztikák 44 721 módosítással frissülnek.

Important

Az SQL Server 2008 R2 (10.50.x) és az SQL Server 2014 (12.x) vagy az SQL Server 2016 (13.x) és újabb verzióiban az adatbázis-kompatibilitási szint 120-es és alacsonyabb verzióiban engedélyezze a 2371-es nyomkövetési jelzőt , hogy az SQL Server csökkenő dinamikus statisztikai frissítési küszöbértéket használjon.

Bár minden forgatókönyv esetében ajánlott, a nyomkövetési jelző 2371 engedélyezése nem kötelező. Az alábbi útmutatással azonban engedélyezheti a 2371 nyomkövetési jelzőt az SQL Server 2016 előtti (13.x) környezetben:

Ha SAP-rendszeren dolgozik, engedélyezze ezt a nyomkövetést. További információkért tekintse meg ezt a blogot a 2371-et jelző nyomkövetési jelzőről.
Ha éjszakai feladatra kell támaszkodnia a statisztikák frissítéséhez, mert az aktuális automatikus frissítés nem aktiválódik elég gyakran, érdemes engedélyeznie a 2371 nyomkövetési jelzőt, hogy a küszöbértéket a tábla számosságához igazítsa.

A Lekérdezésoptimalizáló a lekérdezés összeállítása előtt és a gyorsítótárazott lekérdezési terv végrehajtása előtt ellenőrzi a elavult statisztikákat. A lekérdezés fordítása előtt a Lekérdezésoptimalizáló a lekérdezési predikátum oszlopait, tábláit és indexelt nézeteit használja annak meghatározására, hogy mely statisztikák lehetnek elavultak. A gyorsítótárazott lekérdezési terv végrehajtása előtt az adatbázismotor ellenőrzi, hogy a lekérdezésterv hivatkozik-e up-todátumstatisztikákra.

A AUTO_UPDATE_STATISTICS beállítás az indexekhez, egyoszlopos lekérdezési predikátumokhoz és a CREATE STATISTICS utasítással létrehozott statisztikákhoz létrehozott statisztikai objektumokra vonatkozik. Ez a beállítás a szűrt statisztikákra is vonatkozik.

A sys.dm_db_stats_properties segítségével pontosan nyomon követheti a táblázatban módosított sorok számát, és eldöntheti, hogy manuálisan szeretné-e frissíteni a statisztikákat.

AUTO_UPDATE_STATISTICS mindig ki van kapcsolva a memóriaoptimalizált táblákhoz.

AUTO_UPDATE_STATISTICS_ASYNC

A AUTO_UPDATE_STATISTICS_ASYNC aszinkron statisztikafrissítési beállítás határozza meg, hogy a Lekérdezésoptimalizáló szinkron vagy aszinkron statisztikai frissítéseket használ-e. Alapértelmezés szerint az aszinkron statisztikák frissítése opció ki van kapcsolva, és a lekérdezés-optimalizáló szinkron módon frissíti a statisztikákat. A AUTO_UPDATE_STATISTICS_ASYNC beállítás az indexekhez létrehozott statisztikai objektumokra, a lekérdezési predikátumok egyetlen oszlopára és a CREATE STATISTICS utasítással létrehozott statisztikákra vonatkozik.

Note

Az SQL Server Management Studio aszinkron statisztikai frissítési beállításának beállításához az Adatbázis tulajdonságai ablak Beállítások lapján az automatikus frissítési statisztikák és az automatikus frissítési statisztikák aszinkron beállításának True (Igaz) értékre kell állítania.

A statisztikák frissítése lehet szinkron (alapértelmezett) vagy aszinkron.

A szinkron statisztikák frissítése esetén a lekérdezések mindig a up-todátumstatisztikákkal vannak lefordítva és végrehajtva. Ha a statisztikák elavultak, a lekérdezés-optimalizáló megvárja a frissített statisztikákat a lekérdezés összeállítása és végrehajtása előtt.
Az aszinkron statisztikai frissítések esetén a lekérdezések akkor is a meglévő statisztikákkal állnak össze, ha a meglévő statisztikák elavultak. A Lekérdezésoptimalizáló kiválaszthat egy optimálisnál rosszabb lekérdezéstervet, ha a statisztikák elavultak a lekérdezés fordításakor. A statisztikák általában hamarosan frissülnek. Azok a lekérdezések, amelyek a statisztikák frissítése után futnak le, előnyt élveznek a frissített statisztikák használatából.

Érdemes lehet szinkron statisztikát használni az adatok eloszlását módosító műveletek végrehajtásakor, például tábla csonkolása vagy a sorok nagy százalékának tömeges frissítése esetén. Ha a művelet befejezése után nem frissíti manuálisan a statisztikát, a szinkron statisztikák használatával biztosíthatja, hogy a statisztikák up-todátummal legyenek végrehajtva a lekérdezések a módosított adatokon.

Fontolja meg az aszinkron statisztikák használatát, hogy kiszámíthatóbb lekérdezési válaszidőt érjen el a következő helyzetekben:

Az alkalmazás gyakran ugyanazokat a lekérdezéseket, hasonló lekérdezéseket vagy hasonló gyorsítótárazott lekérdezési csomagokat hajtja végre. A lekérdezési válaszidők kiszámíthatóbbak lehetnek az aszinkron statisztikák frissítéseivel, mint a szinkron statisztikák frissítéseivel, mivel a Lekérdezésoptimalizáló anélkül hajthat végre bejövő lekérdezéseket, hogy up-todátumstatisztikákra kellene várnia. Így elkerülhető, hogy egyes lekérdezések késlekedjenek, mások nem.
Az alkalmazás az ügyfélkérések időtúllépését tapasztalta, amelyet egy vagy több, frissített statisztikákra váró lekérdezés okozott. Bizonyos esetekben a szinkron statisztikákra való várakozás miatt az agresszív időtúllépéssel rendelkező alkalmazások meghiúsulhatnak.

Note

A helyi ideiglenes táblák statisztikái mindig szinkron módon frissülnek, AUTO_UPDATE_STATISTICS_ASYNC beállítástól függetlenül. A globális ideiglenes táblák statisztikái szinkronban vagy aszinkron módon frissülnek a felhasználói adatbázis AUTO_UPDATE_STATISTICS_ASYNC beállításának megfelelően.

Az aszinkron statisztikák frissítését egy háttérkérelem hajtja végre. Ha a kérés készen áll a frissített statisztikák adatbázisba való írására, megkísérli beszerezni a statisztikai metaadat-objektum sémamódosítási zárolását. Ha egy másik munkamenet már rendelkezik zárolással ugyanazon az objektumon, a rendszer letiltja az aszinkron statisztikák frissítését, amíg a sémamódosítási zárolás le nem szerezhető. Hasonlóképpen, az aszinkron statisztikák frissítési háttér-munkamenete blokkolhatja azokat a munkameneteket, amelyeknek séma-stabilitás (Sch-S) zárolást kell szerezniük a statisztikai metaadat-objektumon a lekérdezés összeállításához, miközben ez már a séma-módosítási zárolást birtokolja vagy annak megszerzésére vár. Ezért a nagyon gyakori lekérdezés-fordításokkal és gyakori statisztikai frissítésekkel rendelkező számítási feladatok esetében az aszinkron statisztikák használata növelheti az egyidejűségi problémák valószínűségét a zárolás blokkolása miatt.

Az Azure SQL Database-ben, az Azure SQL Managed Instance-ben és az SQL Server 2022-ben (16.x) kezdődően az aszinkron statisztikai frissítéssel elkerülheti az egyidejűségi problémákat, ha engedélyezi az ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY adatbázis-hatókörű konfigurációt. Ha ez a konfiguráció engedélyezve van, a háttérkérelem megvárja a sémamódosítás (Sch-M) zárolásának beszerzését, és a frissített statisztikákat egy külön alacsony prioritású üzenetsoron megőrzi, így más kérések továbbra is összeállítják a lekérdezéseket a meglévő statisztikákkal. Ha egy másik munkamenet sem tart zárolást a statisztikai metaadat-objektumon, a háttérkérelem beolvasja a sémamódosítási zárolását és frissíti a statisztikákat. Abban a valószínűtlen esetben, ha a háttérkérelem néhány percen belül nem tudja beszerezni a zárolást, a rendszer megszakítja az aszinkron statisztikák frissítését, és a statisztikák nem frissülnek, amíg egy másik automatikus statisztikai frissítés nem aktiválódik, vagy amíg a statisztikák manuálisan nem frissülnek.

Note

Az ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY adatbázis-hatókörű konfigurációs lehetőség elérhető az Azure SQL Database-ben, a felügyelt Azure SQL-példányban és az SQL Serveren az SQL Server 2022-től kezdve (16.x).

AUTO_DROP beállítás

A következőkre vonatkozik: Azure SQL Database, Azure SQL Felügyelt Példány, és SQL Server 2022 (16.x)-től kezdve

Az SQL Server 2022 (16.x) előtti SQL Serverben, ha a statisztikákat egy felhasználó vagy egy harmadik fél által létrehozott eszköz manuálisan hozza létre egy felhasználói adatbázisban, ezek a statisztikai objektumok blokkolhatják vagy zavarhatják a kívánt sémamódosításokat.

Az SQL Server 2022 -től (16.x) kezdődően az automatikus legördülő beállítás alapértelmezés szerint engedélyezve van az összes új és migrált adatbázisban. A AUTO_DROP tulajdonság lehetővé teszi a statisztikai objektumok létrehozását olyan módban, hogy a statisztikai objektum nem blokkolja az azt követő sémamódosítást, hanem szükség szerint elveti a statisztikákat. Így a manuálisan létrehozott statisztikák, amelyek automatikus törlés engedélyezve, úgy viselkednek, mint az automatikusan létrehozott statisztikák.

Az Azure SQL Database, az Azure SQL Managed Instance, valamint az SQL Server 2022 (16.x) és újabb verziókban az automatikusan létrehozott statisztikák mindig úgy viselkednek, mintha a AUTO_DROP lett volna beállítva.

Note

Az automatikusan létrehozott statisztikák automatikus elvetési tulajdonságának beállítása vagy törlése hibákat okozhat. Az automatikusan létrehozott statisztikák mindig automatikus elvetést használnak. Egyes biztonsági másolatok visszaállításkor helytelenül állíthatják be ezt a tulajdonságot a statisztikai objektum következő frissítéséig (manuálisan vagy automatikusan). Az automatikusan létrehozott statisztikák azonban mindig úgy viselkednek, mint az automatikus csökkenési statisztikák. Ha egy adatbázist egy korábbi verzióból az SQL Server 2022-re (16.x) állít vissza, ajánlott végrehajtani sp_updatestats az adatbázison, és meg kell adni a statisztikák automatikus elvetési funkciójának megfelelő metaadatait.

Ha például manuálisan szeretne létrehozni egy statisztikai objektumot a dbo.DatabaseLog táblában:

CREATE STATISTICS [mystats]
    ON [dbo].[DatabaseLog]([DatabaseLogID], [PostTime], [DatabaseUser])
    WITH AUTO_DROP = ON;

Például egy statisztikai objektum automatikus elvetési beállításának frissítése a dbo.DatabaseLog táblán:

UPDATE STATISTICS [dbo].[DatabaseLog] ([mystats])
    WITH AUTO_DROP = ON;

Az automatikus elvetési beállítások meglévő statisztikákon való kiértékeléséhez használja a auto_drop oszlopot a sys.stats -ben.

SELECT object_id,
       [name],
       auto_drop
FROM sys.stats;

További információ: AUTO_DROP.

INCREMENTAL

A: SQL Server 2014 (12.x) és újabb verziókra vonatkozik.

Ha a CREATE STATISTICS növekményes beállítása be van kapcsolva, a létrehozott statisztikák partícióstatisztikánként lesznek létrehozva. Ha ki van kapcsolva, a statisztikai fa el lesz dobva, és az SQL Server újrafordítja a statisztikákat. Az alapértelmezett érték ki van kapcsolva. Ez a beállítás felülírja az adatbázisszintű INCREMENTAL tulajdonságot. További információ a növekményes statisztikák létrehozásáról: CREATE STATISTICS. A partíciónkénti statisztikák automatikus létrehozásáról további információt az Adatbázis tulajdonságai (Beállítások lap) és az ALTER DATABASE SET beállításai című témakörben talál.

Amikor új partíciókat ad hozzá egy nagy táblához, a statisztikákat frissíteni kell az új partíciók belefoglalásához. A teljes táblázat (FULLSCAN vagy SAMPLE beállítások) vizsgálatához szükséges idő azonban meglehetősen hosszú lehet. Emellett a teljes tábla vizsgálata nem szükséges, mert csak az új partíciók statisztikáira lehet szükség. A növekményes beállítás partíciónként hoz létre és tárol statisztikákat, és frissítésekor csak az új statisztikákat igénylő partíciók statisztikáit frissíti.

Ha a partíciónkénti statisztikák nem támogatottak, a beállítás figyelmen kívül lesz hagyva, és figyelmeztetés jön létre. A növekményes statisztikák nem támogatottak a következő statisztikai típusokhoz:

Olyan indexekkel létrehozott statisztikák, amelyek nincsenek partícióhoz igazítva az alaptáblához.
Az Always On olvasható másodlagos adatbázisokon létrehozott statisztikák.
Írásvédett adatbázisokon létrehozott statisztikák.
Szűrt indexeken létrehozott statisztikák.
Nézeteken létrehozott statisztikák.
Belső táblákon létrehozott statisztikák.
Térbeli indexekkel vagy XML-indexekkel létrehozott statisztikák.

Mikor kell statisztikákat létrehozni?

A Lekérdezésoptimalizáló már a következő módokon hoz létre statisztikákat:

A Lekérdezésoptimalizáló statisztikákat hoz létre az index létrehozásakor a táblákon vagy nézeteken lévő indexekhez. Ezek a statisztikák az index kulcsoszlopai alapján jönnek létre. Ha az index szűrt index, a Lekérdezésoptimalizáló szűrt statisztikákat hoz létre a szűrt indexhez megadott sorok ugyanazon részhalmazán. A szűrt indexekről további információt a Szűrt indexek létrehozása és az INDEX LÉTREHOZÁSA című témakörben talál.

Note

Az SQL Server 2014 (12.x) és újabb verzióiban a statisztikák nem úgy jönnek létre, hogy a tábla összes sorát beolvasják egy particionált index létrehozásakor vagy újraépítésekor. Ehelyett a Lekérdezésoptimalizáló az alapértelmezett mintavételezési algoritmust használja a statisztikák létrehozásához. Miután particionált indexekkel frissítette az adatbázist, az indexek hisztogramadataiban eltérést tapasztalhat. Ez a viselkedésbeli változás nem feltétlenül befolyásolja a lekérdezés teljesítményét. A particionált indexekre vonatkozó statisztikák a tábla összes sorának vizsgálatával történő lekéréséhez használja CREATE STATISTICS vagy UPDATE STATISTICS a FULLSCAN záradékkal.
A Lekérdezésoptimalizáló a lekérdezési predikátumokban lévő egyetlen oszlopok statisztikáit hozza létre , amikor AUTO_CREATE_STATISTICS be van kapcsolva.

A legtöbb lekérdezés esetében ez a két statisztikai módszer biztosítja a kiváló minőségű lekérdezési tervet; néhány esetben a CREATE STATISTICS utasítással további statisztikák létrehozásával javíthatja a lekérdezési terveket . Ezek a további statisztikák olyan statisztikai korrelációkat rögzíthetnek, amelyeket a Lekérdezésoptimalizáló nem számol el, amikor indexekhez vagy egyetlen oszlopokhoz hoz létre statisztikákat. Előfordulhat, hogy az alkalmazás további statisztikai korrelációkkal rendelkezik a táblaadatokban, amelyek statisztikai objektumba számítva lehetővé tehetik a Lekérdezésoptimalizáló számára a lekérdezéstervek javítását. A lekérdezési predikátumoszlopok adatsorainak egy részhalmazára vagy többoszlopos statisztikáira vonatkozó szűrt statisztikák például javíthatják a lekérdezéstervet.

Ha a CREATE STATISTICS utasítással hoz létre statisztikákat, javasoljuk, hogy a AUTO_CREATE_STATISTICS beállítás legyen bekapcsolva, hogy a Lekérdezésoptimalizáló továbbra is rutinszerűen hozzon létre egyoszlopos statisztikákat a lekérdezési predikátumoszlopokhoz. A lekérdezési predikátumokról további információt a Keresési feltétel című témakörben talál.

Az alábbi esetekben érdemes lehet statisztikákat létrehozni a CREATE STATISTICS utasítással:

Az adatbázismotor finomhangolási tanácsadója statisztikák létrehozását javasolja.
A lekérdezési predikátum több korrelált oszlopot tartalmaz, amelyek még nem kulcsok ugyanabban az indexben.
A lekérdezés az adatok egy részhalmazából választ.
A lekérdezésből hiányoznak statisztikák.

Note

Az In-Memory OLTP-hez kapcsolódó táblákra és statisztikákra vonatkozó információkért tekintse meg Memory-Optimized táblák statisztikáit.

A lekérdezési predikátum több korrelált oszlopot tartalmaz

Ha egy lekérdezési predikátum több oszlopot tartalmaz, amelyek oszlopközi kapcsolatokkal és függőségekkel rendelkeznek, a több oszlop statisztikái javíthatják a lekérdezéstervet. A több oszlopra vonatkozó statisztikák oszlopközi korrelációs statisztikákat, úgynevezett sűrűségeket tartalmaznak, amelyek nem érhetők el az egyoszlopos statisztikákban. A sűrűségek növelhetik a számosság becslését, ha a lekérdezés eredményei több oszlop közötti adatkapcsolatoktól függenek.

Ha az oszlopok már ugyanabban az indexben vannak, a többoszlopos statisztikai objektum már létezik, és nem szükséges manuálisan létrehozni. Ha az oszlopok még nem ugyanabban az indexben szerepelnek, akkor többoszlopos statisztikákat hozhat létre az oszlopokon lévő index létrehozásával vagy a CREATE STATISTICS utasítással. Az index fenntartásához több rendszererőforrásra van szükség, mint egy statisztikai objektum. Ha az alkalmazás nem igényli a többoszlopos indexet, az index létrehozása nélkül is gazdaságossá teheti a rendszererőforrásokat a statisztikai objektum létrehozásával.

Többoszlopos statisztikák létrehozásakor a statisztikai objektumdefiníció oszlopainak sorrendje befolyásolja a sűrűségek hatékonyságát a számosságbecslésekhez. A statisztikai objektum a statisztikai objektumdefinícióban lévő kulcsoszlopok minden előtagja esetében tárolja a sűrűséget. A sűrűségekkel kapcsolatos további információkért lásd ezen a lapon a Sűrűség szakaszt.

A számosságbecslésekhez hasznos sűrűségek létrehozásához a lekérdezési predikátum oszlopainak meg kell egyeznie a statisztikai objektumdefiníció oszlopainak egyik előtagjának. Az alábbi példa egy többoszlopos statisztikai objektumot hoz létre az oszlopok LastName, MiddleName és FirstName alapján.

USE AdventureWorks2022;
GO

IF EXISTS (SELECT name
           FROM sys.stats
           WHERE name = 'LastFirst'
                 AND object_ID = OBJECT_ID('Person.Person'))
    DROP STATISTICS Person.Person.LastFirst;
GO

CREATE STATISTICS LastFirst
    ON Person.Person(LastName, MiddleName, FirstName);
GO

Ebben a példában a statisztikai objektum LastFirst sűrűsége a következő oszlopelőtagokhoz tartozik: (LastName), (LastName, MiddleName)és (LastName, MiddleName, FirstName). A sűrűség nem érhető el (LastName, FirstName). Ha a lekérdezés LastName és FirstName használ, de nem használja a MiddleName-t, a sűrűség nem érhető el a számosságbecslésekhez.

A lekérdezés az adatok egy részhalmazából választ

Amikor a Lekérdezésoptimalizáló egyetlen oszlophoz és indexhez hoz létre statisztikákat, az összes sor értékeinek statisztikáit hozza létre. Ha a lekérdezések a sorok egy részhalmazából választanak, és a sorok egy részhalmaza egyedi adateloszlással rendelkezik, a szűrt statisztikák javíthatják a lekérdezési terveket. Szűrt statisztikákat a CREATE STATISTICS utasítással és a WHERE záradékkal hozhat létre a szűrő predikátum kifejezésének meghatározásához.

Az AdventureWorks2025 használatával például a Production.Product táblázat minden terméke a Production.ProductCategory táblázat négy kategóriájának egyikéhez tartozik: Bikes, Components, Clothingés Accessories. Az egyes kategóriák eltérő adateloszlást tartalmaznak a súlyokhoz: a kerékpárok súlyozása 13,77 és 30,0 között, az összetevők súlyozása 2,12 és 1050,00 között mozog bizonyos NULL értékekkel, a ruházati súlyok mind NULL, és a kiegészítő súlyok is NULL.

A Bikes kerékpárok súlyának szűrt statisztikái például pontosabb statisztikákat biztosítanak a Lekérdezésoptimalizáló számára, és javíthatja a lekérdezésterv minőségét a teljes táblázatos statisztikákhoz vagy a Súly oszlop nem létező statisztikáihoz képest. A kerékpár súlyoszlopa jó jelölt a szűrt statisztikákhoz, de nem feltétlenül jó jelölt a szűrt indexhez, ha a súlykeresések száma viszonylag kicsi. A szűrt index által biztosított keresések teljesítménynövekedése nem feltétlenül haladják meg a szűrt index adatbázishoz való hozzáadásának további karbantartási és tárolási költségeit.

Az alábbi utasítás létrehozza a BikeWeights szűrt statisztikákat a következő alkategóriákban Bikes: . A szűrt predikátum kifejezés úgy definiálja a kerékpárokat, hogy az összes kerékpár-alkategóriát számba veszi az összehasonlítással Production.ProductSubcategoryID IN (1,2,3). A predikátum nem tudja használni a Bikes kategórianevet, mert a Production.ProductCategory táblában van tárolva, és a szűrőkifejezés összes oszlopának ugyanabban a táblában kell lennie.

USE AdventureWorks2022;
GO
IF EXISTS ( SELECT name FROM sys.stats
    WHERE name = 'BikeWeights'
    AND object_ID = OBJECT_ID ('Production.Product'))
DROP STATISTICS Production.Product.BikeWeights;
GO
CREATE STATISTICS BikeWeights
    ON Production.Product (Weight)
WHERE ProductSubcategoryID IN (1,2,3);
GO

A Lekérdezésoptimalizáló a BikeWeights szűrt statisztikák használatával javíthatja a következő lekérdezés lekérdezéstervét, amely kiválasztja az összes olyan kerékpárt, amely nagyobb súlyú, mint 25.

SELECT P.Weight AS Weight,
       S.Name AS BikeName
FROM Production.Product AS P
     INNER JOIN Production.ProductSubcategory AS S
         ON P.ProductSubcategoryID = S.ProductSubcategoryID
WHERE P.ProductSubcategoryID IN (1, 2, 3)
      AND P.Weight > 25
ORDER BY P.Weight;
GO

A lekérdezés azonosítja a hiányzó statisztikákat

Ha egy hiba vagy egyéb esemény megakadályozza, hogy a Lekérdezésoptimalizáló statisztikákat hozzon létre, a Lekérdezésoptimalizáló statisztikai adatok használata nélkül hozza létre a lekérdezéstervet. A Lekérdezésoptimalizáló hiányzóként jelöli meg a statisztikákat, és a lekérdezés következő végrehajtásakor megpróbálja újragenerálni a statisztikákat.

A hiányzó statisztikák figyelmeztetésként jelennek meg (a tábla neve piros szövegben), amikor egy lekérdezés végrehajtási terve grafikusan jelenik meg az SQL Server Management Studióval. Emellett a Hiányzó oszlopstatisztika eseményosztály SQL Server Profilerrel való figyelése azt is jelzi, hogy mikor hiányoznak a statisztikák. További információ: Hibák és figyelmeztetések eseménykategória (adatbázismotor).

Ha a statisztikák hiányoznak, hajtsa végre a következő lépéseket:

Ellenőrizze, hogy AUTO_CREATE_STATISTICS és AUTO_UPDATE_STATISTICS be vannak-e kapcsolva.
Bizonyosodjon meg arról, hogy az adatbázis nem csak olvasható. Ha az adatbázis írásvédett, egy új statisztikai objektum nem menthető.
Hozza létre a hiányzó statisztikákat a CREATE STATISTICS utasítással.

Ideiglenes statisztikák

Ha egy írásvédett adatbázis vagy írásvédett pillanatkép statisztikái hiányoznak vagy elavultak, az adatbázismotor ideiglenes statisztikákat hoz létre és tart fenn a tempdb területen. Amikor az adatbázismotor ideiglenes statisztikákat hoz létre, a statisztikai név hozzá lesz fűzve a _readonly_database_statistic utótaghoz, hogy megkülönböztesse az ideiglenes statisztikákat az állandó statisztikáktól. A _readonly_database_statistic utótag az adatbázismotor által létrehozott statisztikák számára van fenntartva. Az ideiglenes statisztikák szkriptjei írás-olvasási adatbázisban hozhatók létre és futtathatók. A szkriptek használatakor a Management Studio a statisztikai név utótagját _readonly_database_statistic-ról_readonly_database_statistic_scripted-ra módosítja.

Csak az adatbázismotor hozhat létre és frissíthet ideiglenes statisztikákat. Az ideiglenes statisztikákat azonban törölheti és figyelheti a statisztikai tulajdonságokat ugyanazokkal az eszközökkel, amelyeket állandó statisztikákhoz használ:

Ideiglenes statisztikák törlése a DROP STATISTICS utasítással.
Statisztikák monitorozása a sys.stats és sys.stats_columns katalógusnézetek használatával. A sys.stats rendszerkatalógus nézet tartalmazza az is_temporary oszlopot, amely jelzi, hogy mely statisztikák állandóak és melyek ideiglenesek.

Mivel az ideiglenes statisztikákat a tempdbrendszer tárolja, az adatbázismotor újraindítása eltávolítja az összes ideiglenes statisztikát.

Mint minden statisztika esetében, az ideiglenes statisztikák létrehozásához és frissítéséhez sémamódosítási (Sch-M) zárolás szükséges az objektumon. Ez a zárolás blokkolhat más lekérdezéseket és folyamatokat, beleértve az elsődleges replika tranzakcióit alkalmazó másodlagos replikák rendszer-újraművelési folyamatát is. Ha ez a blokkolás hatással van a lekérdezési számítási feladatokra vagy az adatok propagálására, letilthatja az ideiglenes statisztikák automatikus létrehozását és frissítését az adatbázis- és READABLE_SECONDARY_TEMPORARY_STATS_AUTO_CREATEREADABLE_SECONDARY_TEMPORARY_STATS_AUTO_UPDATE konfigurációk használatával.

Mikor kell frissíteni a statisztikákat?

A Lekérdezésoptimalizáló határozza meg, hogy a statisztikák mikor lehetnek elavultak, majd frissíti őket, amikor egy lekérdezési tervhez szükség van rájuk. Bizonyos esetekben javíthatja a lekérdezési tervet, és ezáltal javíthatja a lekérdezési teljesítményt azáltal, hogy gyakrabban frissíti a statisztikákat, mint amikor AUTO_UPDATE_STATISTICS be van kapcsolva. A statisztikákat az UPDATE STATISTICS utasítással vagy a tárolt eljárással sp_updatestatsfrissítheti.

A statisztikák frissítése biztosítja, hogy a lekérdezések up-todátumstatisztikákkal legyenek lefordítva. A statisztikák bármilyen folyamaton keresztüli frissítése automatikusan újrafordíthatja a lekérdezési terveket. Javasoljuk, hogy ne frissítse manuálisan a statisztikákat túl gyakran, mert teljesítménybeli különbség van a lekérdezéstervek javítása és a lekérdezések újrafordításához szükséges idő között. Az adott kompromisszumok az alkalmazástól függenek.

Amikor a statisztikákat UPDATE STATISTICS vagy sp_updatestats segítségével frissíti, javasoljuk, hogy az AUTO_UPDATE_STATISTICS legyen bekapcsolva, hogy a Lekérdezésoptimalizáló rendszeresen frissítse a statisztikákat.

Az oszlopok, indexek, táblák vagy indexelt nézetek statisztikáinak frissítéséről a STATISZTIKA FRISSÍTÉSE című témakörben talál további információt.
Az adatbázis összes felhasználó által definiált és belső táblájának statisztikáinak frissítéséről a tárolt sp_updatestatscímű témakörben olvashat.
Az automatikus statisztikai frissítések küszöbértékével kapcsolatos további információkért lásd AUTO_UPDATE_STATISTICS Beállítás című témakört.

Ha AUTO_UPDATE_STATISTICS ki van kapcsolva, a terv újrafordítása számos más okból is előfordulhat, de a elavult statisztikák frissítései miatt nem történik meg automatikusan. Ha AUTO_UPDATE_STATISTICS ki van kapcsolva, a statisztikai frissítések csak más manuálisan ütemezett folyamatokon, például karbantartási terveken keresztül történnek. A AUTO_UPDATE_STATISTICS KI állítás suboptimális lekérdezési terveket és gyenge lekérdezési teljesítményt eredményezhet.

Elavult statisztikák észlelése

A statisztikák legutóbbi frissítésének időpontjának meghatározásához használja a sys.dm_db_stats_properties vagy STATS_DATE függvényeket.

Fontolja meg a következő feltételek statisztikáinak frissítését:

A lekérdezések végrehajtási ideje lassú.
A beszúrási műveletek növekvő vagy csökkenő kulcsoszlopokon történnek.
Karbantartási műveletek után.

Példák a statisztikák manuális frissítésére: UPDATE STATISTICS.

A lekérdezések végrehajtási ideje lassú

Ha a lekérdezés válaszideje lassú vagy kiszámíthatatlan, a további hibaelhárítási lépések végrehajtása előtt győződjön meg arról, hogy a lekérdezések up-todátumstatisztikával rendelkeznek.

A beszúrási műveletek növekvő vagy csökkenő kulcsoszlopokon történnek

A növekvő vagy csökkenő kulcsoszlopokra, például az IDENTITY vagy a valós idejű időbélyeg-oszlopokra vonatkozó statisztikák gyakoribb statisztikai frissítéseket igényelhetnek, mint a Lekérdezésoptimalizáló. A beszúrási műveletek új értékeket fűznek növekvő vagy csökkenő oszlopokhoz. Előfordulhat, hogy a hozzáadott sorok száma túl kicsi ahhoz, hogy elindítsa a statisztikai frissítéseket. Ha a statisztikák nem up-todátumot, és a lekérdezések a legutóbb hozzáadott sorok közül választanak, az aktuális statisztikák nem rendelkeznek számossági becslésekkel ezekre az új értékekre. Ez pontatlan számosságbecsléseket és lassú lekérdezési teljesítményt eredményezhet.

A legutóbbi értékesítési rendelési dátumok közül kiválasztott lekérdezések például pontatlan számossági becslésekkel rendelkeznek, ha a statisztikák nem frissülnek, hogy a legutóbbi értékesítési rendelés dátumára vonatkozó számosságbecsléseket is tartalmazzanak.

Karbantartási műveletek után

Fontolja meg a statisztikák frissítését az adatok eloszlását módosító karbantartási eljárások végrehajtása után, például egy tábla csonkolása vagy a sorok nagy részének tömeges beszúrása után. Ez elkerülheti a lekérdezések feldolgozásának jövőbeni késését, miközben a lekérdezések megvárják az automatikus statisztikai frissítéseket.

Az olyan műveletek, mint az újraépítés, a töredezettségmentesítés vagy az index átrendezése, nem módosítják az adatok eloszlását. Ezért nem kell frissítenie a statisztikákat az ALTER INDEX ÚJRAÉPÍTÉSe, a DBCC DBREINDEX, a DBCC INDEXDEFRAG vagy az ALTER INDEX REORGANIZE műveletek végrehajtása után. A Lekérdezésoptimalizáló frissíti a statisztikákat, amikor ALTER INDEX REBUILD vagy DBCC DBREINDEX segítségével újraépít egy indexet egy táblán vagy nézeten, azonban ez a statisztikai frissítés az index újbóli létrehozásának mellékterméke. A Lekérdezésoptimalizáló nem frissíti a statisztikákat a DBCC INDEXDEFRAG vagy ALTER INDEX REORGANIZE műveletek után.

Tip

Az SQL Server 2016 -tól (13.x) SP1 CU4-től kezdve használja a STATISZTIKÁK létrehozása vagy a STATISZTIKA FRISSÍTÉSE PERSIST_SAMPLE_PERCENT lehetőséget, hogy meghatározott mintavételi százalékot állítson be és őrizze meg az olyan későbbi statisztikai frissítésekhez, amelyek nem határoznak meg explicit módon mintavételezési százalékot.

Automatikus index- és statisztikakezelés

Intelligens megoldások, például adaptív indextöredezettség-mentesítés használata egy vagy több adatbázis indextöredezettség-mentesítésének és statisztikáinak automatikus kezeléséhez. Ez az eljárás automatikusan kiválasztja, hogy újraépít vagy átrendez egy indexet a töredezettségi szintnek megfelelően, többek között más paraméterekkel, és lineáris küszöbértékkel frissíti a statisztikákat.

Statisztikákat hatékonyan használó lekérdezések

Bizonyos lekérdezési implementációk, például a lekérdezési predikátum helyi változói és összetett kifejezései, optimálisnál rosszabb lekérdezési tervekhez vezethetnek. Ennek elkerülésében segíthet, ha a lekérdezéstervezési irányelveket követve hatékonyan használja a statisztikákat. A lekérdezési predikátumokról további információt a Keresési feltétel című témakörben talál.

A lekérdezési terveket úgy javíthatja, ha olyan lekérdezéstervezési irányelveket alkalmaz, amelyek hatékonyan használják a statisztikákat a lekérdezési predikátumokban használt kifejezések, változók és függvények számosságbecslésének javítására. Ha a Lekérdezésoptimalizáló nem ismeri egy kifejezés, változó vagy függvény értékét, nem tudja, hogy melyik értéket keresse meg a hisztogramban, ezért nem tudja lekérni a hisztogramból a legjobb számosságbecslést. A Lekérdezésoptimalizáló ehelyett a hisztogramban szereplő minták összes sorának egyedi értékenkénti átlagszámán alapuló számosság becslését végzi. Ez az optimálisnál alacsonyabb számosságbecslésekhez vezet, és ronthatja a lekérdezés teljesítményét. További információért a hisztogramokról lásd az ezen az oldalon található „hisztogram” szakaszt vagy a sys.dm_db_stats_histogram-t.

Az alábbi irányelvek bemutatják, hogyan írhat lekérdezéseket a lekérdezéstervek javítására a számosságbecslések javításával.

A kifejezések számosságbecslésének javítása

A kifejezések számosságbecsléseinek javítása érdekében kövesse az alábbi irányelveket:

Amikor csak lehetséges, egyszerűsítse a kifejezéseket állandókkal. A Lekérdezésoptimalizáló nem értékeli ki az állandókat tartalmazó összes függvényt és kifejezést a számosságbecslések meghatározása előtt. Egyszerűsítse például a kifejezést ABS(-100) a következőre 100: .
Ha a kifejezés több változót használ, fontolja meg egy számított oszlop létrehozását a kifejezéshez, majd hozzon létre statisztikákat vagy indexet a számított oszlopban. A lekérdezési predikátum WHERE PRICE + Tax > 100 például jobb számosságbecsléssel rendelkezhet, ha számítási oszlopot hoz létre a kifejezéshez Price + Tax.

Változók és függvények számosságbecslésének javítása

A változókra és függvényekre vonatkozó számosságbecslések javításához kövesse az alábbi irányelveket:

Ha a lekérdezési predikátum helyi változót használ, fontolja meg a lekérdezés újraírását, hogy egy paramétert használjon helyi változó helyett. A helyi változó értéke nem ismert, amikor a Lekérdezésoptimalizáló létrehozza a lekérdezés-végrehajtási tervet. Amikor egy lekérdezés paramétert használ, a Lekérdezésoptimalizáló a tárolt eljárásnak átadott első tényleges paraméterérték számosságbecslését használja.
Fontolja meg egy szabványos vagy ideiglenes tábla használatát a többutas táblaértékű függvények (mstvf) eredményeinek tárolásához. A Lekérdezésoptimalizáló nem hoz létre statisztikákat többutas táblaértékű függvényekhez. Ezzel a módszerrel a Lekérdezésoptimalizáló statisztikákat hozhat létre a táblaoszlopokon, és felhasználhatja őket egy jobb lekérdezési terv létrehozásához.
Érdemes lehet szabványos vagy ideiglenes táblát használni a táblaváltozók helyettesítésére. A Lekérdezésoptimalizáló nem hoz létre statisztikai adatokat a táblaváltozókhoz. Ezzel a módszerrel a Lekérdezésoptimalizáló statisztikákat hozhat létre a táblaoszlopokon, és felhasználhatja őket egy jobb lekérdezési terv létrehozásához. Vannak kompromisszumok annak meghatározásában, hogy ideiglenes táblát vagy táblaváltozót használnak-e; A tárolt eljárásokban használt táblaváltozók a tárolt eljárás kevesebb újrafordítását okozzák, mint az ideiglenes táblák. Az alkalmazástól függően előfordulhat, hogy a táblaváltozó helyett ideiglenes tábla használata nem növeli a teljesítményt.

Ha egy tárolt eljárás olyan lekérdezést tartalmaz, amely egy átadott paramétert használ, a lekérdezésben való használat előtt ne módosítsa a paraméter értékét a tárolt eljáráson belül. A lekérdezés számossági becslései a megadott paraméterértéken alapulnak, nem pedig a frissített értéken. A paraméter értékének módosításának elkerülése érdekében a lekérdezést átírhatja két tárolt eljárás használatára.

Például az alábbi tárolt eljárás Sales.GetRecentSales megváltoztatja a @date paraméter értékét, amikor @dateNULL.

USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetRecentSales;
GO

CREATE PROCEDURE Sales.GetRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID
        AND h.OrderDate > @date;
END
GO

Ha a tárolt eljárás Sales.GetRecentSales első hívása átad egy NULL-t a @date paraméter számára, a Lekérdezésoptimalizáló kompilálja a tárolt eljárást a @date = NULL számosság becslésével annak ellenére, hogy a lekérdezési predikátumot nem hívja meg @date = NULL a rendszer. Ez a számosságbecslés jelentősen eltérhet a tényleges lekérdezés eredményében szereplő sorok számától. Ennek eredményeképpen a Lekérdezésoptimalizáló kiválaszthat egy optimálisnál rosszabb lekérdezési tervet. Ennek elkerülése érdekében a tárolt eljárást két eljárásra írhatja át az alábbiak szerint:

USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetNullRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetNullRecentSales;
GO

CREATE PROCEDURE Sales.GetNullRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    EXECUTE Sales.GetNonNullRecentSales @date;
END
GO

IF OBJECT_ID('Sales.GetNonNullRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetNonNullRecentSales;
GO

CREATE PROCEDURE Sales.GetNonNullRecentSales
@date DATETIME
AS
BEGIN
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID
        AND h.OrderDate > @date;
END
GO

Számosságbecslések javítása lekérdezési tippekkel

A helyi változók számosságbecslésének javítása érdekében használhatja a OPTIMIZE FOR <value>OPTIMIZE FOR UNKNOWN lekérdezési RECOMPILEtippeket. További információ: Lekérdezési tippek.

Egyes alkalmazások esetében előfordulhat, hogy a lekérdezés újrafordítása minden alkalommal, amikor végrehajtja, túl sok időt vehet igénybe. A OPTIMIZE FOR lekérdezési tipp akkor is segíthet, ha nem használja a RECOMPILE lehetőséget. Hozzáadhat például egy OPTIMIZE FOR beállítást a tárolt eljáráshoz Sales.GetRecentSales egy adott dátum megadásához. Az alábbi példa hozzáadja a OPTIMIZE FOR lehetőséget az Sales.GetRecentSales eljáráshoz.

USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetRecentSales;
GO

CREATE PROCEDURE Sales.GetRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID AND h.OrderDate > @date
    OPTION (OPTIMIZE FOR (@date = '2004-05-01 00:00:00.000'));
END
GO

Számosságbecslések javítása terv-útmutatókkal

Egyes alkalmazások esetében előfordulhat, hogy a lekérdezéstervezési irányelvek nem érvényesek, mert nem módosíthatja a lekérdezést, vagy a RECOMPILE lekérdezési tipp túl sok újrafordítást okozhat. A tervútmutatók segítségével más tippeket is megadhat, például a USE PLAN parancsot, amellyel szabályozhatja a lekérdezés viselkedését az alkalmazás szállítójánál végzett alkalmazásmódosítások vizsgálata során. A terv útmutatóiról további információt a Terv útmutatói című témakörben talál.

Az Azure SQL Database-ben fontolja meg a Query Store-tippeket, hogy tervsegédek helyett terveket kényszerítsen ki. További információ: Query Store-tippek.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-18

statisztika

Összetevők és fogalmak

statisztika

Histogram

Sűrűségvektor

Szűrt statisztikák

Statisztikai beállítások

AUTO_CREATE_STATISTICS lehetőség

AUTO_UPDATE_STATISTICS lehetőség

AUTO_UPDATE_STATISTICS_ASYNC

AUTO_DROP beállítás

INCREMENTAL

Mikor kell statisztikákat létrehozni?

A lekérdezési predikátum több korrelált oszlopot tartalmaz

A lekérdezés az adatok egy részhalmazából választ

A lekérdezés azonosítja a hiányzó statisztikákat

Ideiglenes statisztikák

Mikor kell frissíteni a statisztikákat?

Elavult statisztikák észlelése

A lekérdezések végrehajtási ideje lassú

A beszúrási műveletek növekvő vagy csökkenő kulcsoszlopokon történnek

Karbantartási műveletek után

Automatikus index- és statisztikakezelés

Statisztikákat hatékonyan használó lekérdezések

A kifejezések számosságbecslésének javítása

Változók és függvények számosságbecslésének javítása

Számosságbecslések javítása lekérdezési tippekkel

Számosságbecslések javítása terv-útmutatókkal

Kapcsolódó tartalom

Visszajelzés

További források