statisztika

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL-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

SQL Server csak egyetlen oszlophoz készít hisztogramokat – a statisztikai objektum kulcsoszlopainak első oszlopát.

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 a sorrend azért lehetséges, mert a bemeneti értékek rendezve vannak). Ha új tartományt hoz létre, a folyamat egyetlen tartományba összecsukja a meglévő, szomszédos tartományok egy párját. 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 mintával készült, akkor a equal_rows, range_rows, distinct_range_rows és average_range_rows értékei becslések, 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 bal oldalán lévő szilárd terület az oszlopértékek tartományát és az egyes oszlopértékek előfordulási gyakoriságá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ányban (range_rows) szereplő értékek teljes számának 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 objektum kulcsoszlopokkal CustomerIdrendelkezik, ItemIdés Pricea sűrűség kiszámítása az alábbi oszlopelőtagokon történik.

Oszlop előtagja 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

Konfigurálhat olyan beállításokat, amelyek befolyásolják, hogy a rendszer mikor és hogyan hozza létre és frissíti a statisztikákat. Ezeket a beállításokat csak az adatbázis szintjén állíthatja be.

AUTO_CREATE_STATISTICS beállítás

Amikor bekapcsolja az automatikus statisztikai létrehozási beállítást, AUTO_CREATE_STATISTICS 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ési terv 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 az adatbázis létrehoz-e statisztikákat 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

Amikor bekapcsolja az automatikus frissítési statisztikák beállítást, AUTO_UPDATE_STATISTICS, a Lekérdezésoptimalizáló meghatározza, hogy mikor lehetnek elavultak a statisztikák, és 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ó megszámolja a legutóbbi statisztikai frissítés óta végrehajtott sormódosítások számát, és összehasonlítja ezt a számot egy küszöbértéktel annak megállapításához, hogy a statisztikák elavultak-e. A küszöbérték a tábla kardinálitásán alapul, amely a tábla vagy az indexelt nézet sorainak száma.

A statisztikák sormódosítások alapján történő elavultnak jelölése akkor is megtörténik, ha a AUTO_UPDATE_STATISTICS beállítás értéke OFF. Ha ez a AUTO_UPDATE_STATISTICS lehetőség, OFFa rendszer nem frissíti a statisztikákat, még akkor sem, ha elavultként jelöli meg őket. A tervek továbbra is a elavult statisztikai objektumokat használják. A(z) AUTO_UPDATE_STATISTICSOFF értékre állítása nem optimális lekérdezési terveket és romló lekérdezési teljesítményt okozhat. Állítsa be a AUTO_UPDATE STATISTICS beállítást a következőre ON: .

  • 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 függően 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 000 sort tartalmaz, a számítás 500 + (0.2 * 20,000) = 4,500, és a statisztikák 4 500 módosításonként frissülnek.

  • A 2016-os SQL Server (13.x) és az adatbázis-kompatibilitási szint 130-tól kezdve a Database Engine csökkenő, dinamikus újrafordítási küszöbértéket 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, a SQL Server 2014-es (12.x) küszöbértékek é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 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 egy é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, fontolja meg a 2371 nyomkövetési jelző engedélyezését, hogy a küszöbértéket táblázat-számosságra állí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 létrehozott statisztikai objektumokra, a lekérdezési predikátumok egyoszlopos oszlopaihoz és az CREATE STATISTICS utasítással létrehozott statisztikákra 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 OFF memóriaoptimalizált táblákhoz használható.

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 statisztikafrissítési beállítás értéke OFF, és a Lekérdezésoptimalizá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 az CREATE STATISTICS utasítással létrehozott statisztikákra vonatkozik.

Note

Az aszinkron statisztikák frissítési beállításának SQL Server Management Studio beállításához az Adatbázis tulajdonságai ablak Beállítások lapján állítsa az automatikus frissítési statisztikákat és az automatikus frissítési statisztikákat aszinkron módonIgaz értékre.

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ákat, a szinkron statisztikák használata biztosítja, hogy a statisztikák naprakészek legyenek, mire a lekérdezéseknek szükségük lesz rájuk.

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 az agresszív időtúllépésekkel rendelkező alkalmazások meghiúsulását okozhatja.

Note

A helyi ideiglenes táblák statisztikái a beállítástól függetlenül mindig szinkron módon frissülnek AUTO_UPDATE_STATISTICS_ASYNC . A globális ideiglenes táblák statisztikái szinkronban vagy aszinkron módon frissülnek a AUTO_UPDATE_STATISTICS_ASYNC felhasználói adatbázis 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, valamint az SQL Server 2022-től (16.x) kezdődően elkerülheti a lehetséges párhuzamossági problémákat az aszinkron statisztikafrissítés használatával, ha engedélyezi az ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITYadatbá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ébe tartozó konfigurációs lehetőség Azure SQL Database, Azure SQL Managed Instance és SQL Server 2022-SQL Server (16.x) verziótól kezdve érhető el.

AUTO_DROP opció

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

A 2022-SQL Server (16.x) előtti SQL Server, ha manuálisan hoz létre statisztikákat, vagy külső eszközt használ egy felhasználói adatbázisban, ezek a statisztikai objektumok blokkolhatják vagy zavarhatják a 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. Ha engedélyezi a AUTO_DROP tulajdonságot, az adatbázis olyan módban hozza létre a statisztikai objektumokat, 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.

A Azure SQL Database Azure SQL Managed Instance és SQL Server 2022-ben (16.x) és újabb verziókban az automatikusan létrehozott statisztikák mindig úgy viselkednek, mintha engedélyezve lenne a AUTO_DROP.

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(z) INCREMENTALCREATE STATISTICS beállítását ON értékre állítja, partíciónkénti statisztikákat hoz létre. Amikor ezt OFF értékre állítja, az adatbázis eldobja a statisztikai fát, és újraszámítja a statisztikákat. Az alapértelmezett érték a OFF. Ez a beállítás felülírja az adatbázisszintű INCREMENTAL tulajdonságot.

Amikor új partíciókat ad hozzá egy nagy táblához, frissítenie kell a statisztikákat, hogy az új partíciókat is tartalmazza. A teljes táblázat (FULLSCAN vagy SAMPLE beállítások) vizsgálatához szükséges idő azonban 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 hozza létre és tárolja a 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, az adatbázis figyelmen kívül hagyja a beállítást, és figyelmeztetést hoz létre. A növekményes statisztikák nem támogatottak a következő statisztikai típusok esetében:

  • 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.
  • Csak olvasható 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:

  1. Amikor táblákon vagy nézeteken hoz létre indexet, a Lekérdezésoptimalizáló statisztikákat hoz létre az 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 indexekkel kapcsolatos további információkért lásd: Szűrt indexek létrehozása és CREATE INDEX.

    Note

    A SQL Server 2014-ben (12.x) és újabb verziókban az adatbázis nem a tábla összes sorának beolvasásával hozza létre a statisztikákat 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. Ha a particionált indexekre vonatkozó statisztikákat a tábla összes sorának beolvasásával szeretné lekérni, használja a(z) CREATE STATISTICS vagy UPDATE STATISTICS utasítást a FULLSCAN záradékkal.

  2. 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 további statisztikák létrehozásával javíthatja a lekérdezési terveket az CREATE STATISTICS utasítás használatával. 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 az CREATE STATISTICS utasítás használatával hoz létre statisztikákat, tartsa meg a AUTO_CREATE_STATISTICS lehetőséget ON , 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.

Érdemes lehet statisztikákat létrehozni az utasítás használatával, CREATE STATISTICS ha az alábbi feltételek bármelyike teljesül:

  • 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 kell manuálisan létrehoznia. Ha az oszlopok még nincsenek ugyanabban az indexben, akkor többoszlopos statisztikákat is létrehozhat az oszlopok indexének létrehozásával vagy az CREATE STATISTICS utasítás használatával. 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 tekintse meg a jelen cikk Sűrűség szakaszát.

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 záradékkal rendelkező utasítással 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 az CREATE STATISTICS utasítás használatával.

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:

  • Az utasítás használatával törölje az DROP STATISTICS ideiglenes statisztikákat.
  • 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ó meghatározza, hogy mikor lehetnek elavultak a statisztikák, majd szükség esetén frissíti őket egy lekérdezéstervhez. Bizonyos esetekben javíthatja a lekérdezési tervet, és ezáltal javíthatja a lekérdezési teljesítményt a statisztikák gyakoribb frissítésével, mint AUTO_UPDATE_STATISTICS esetén ON. A statisztikákat az utasítás vagy a UPDATE STATISTICS tárolt eljárás sp_updatestatshasználatával frissí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ármely folyamat általi frissítése automatikusan kiválthatja a lekérdezési tervek újrafordítását. 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.

Ha a statisztikákat a(z) UPDATE STATISTICS vagy sp_updatestats használatával frissíti, hagyja a(z) AUTO_UPDATE_STATISTICS beállítást ON értéken, hogy a Lekérdezésoptimalizáló rendszeresen frissítse a statisztikákat.

  • Az oszlop, index, tábla vagy indexelt nézet statisztikáinak frissítéséről további információt a következő témakörben talál UPDATE STATISTICS:

  • 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 be AUTO_UPDATE_STATISTICSvan állítvaOFF, a terv újrafordítása számos más okból is előfordulhat, de nem történik meg automatikusan a elavult statisztikák frissítései miatt. Ha a(z) AUTO_UPDATE_STATISTICS értékét OFF értékre állítja, a statisztikák frissítése csak más, manuálisan ütemezett folyamatok során történik, például karbantartási tervek részeként. AUTO_UPDATE_STATISTICS A beállítás OFF így optimálisnál rosszabb lekérdezési terveket és csökkentett lekérdezési teljesítményt okozhat.

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 IDENTITY 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 naprakészek, és a lekérdezések a legutóbb hozzáadott sorokból választanak ki, akkor az aktuális statisztikák nem tartalmaznak számossági becsléseket ezekről az új értékekről. Ez a feltétel 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éseket tartalmaznak, ha a statisztikák nem frissülnek, hogy a legfrissebb értékesítési rendelési dátumokra vonatkozó számosságbecsléseket 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. A statisztikák proaktív frissítése elkerülheti a lekérdezések feldolgozásának későbbi késését, miközben a lekérdezések megvárják az automatikus statisztikák frissítését.

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 ÚJRAÉPÍTÉS, ALTER INDEX, a DBCC INDEXDEFRAG vagy a REORGANIZE műveletek végrehajtása ALTER INDEXutá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

A SQL Server 2016 (13.x) SP1 CU4 verziótól kezdve a CREATE STATISTICS vagy a UPDATE STATISTICS PERSIST_SAMPLE_PERCENT kapcsolójával beállíthat és megőrizhet egy adott mintavételezési százalékot a későbbi olyan statisztikafrissítésekhez, amelyek nem adnak meg kifejezetten 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-e vagy átrendez egy indexet a töredezettségi szintnek megfelelően, más paraméterek mellett, és lineáris küszöbértékkel frissíti a statisztikákat.

A lekérdezésoptimalizáló által használt statisztikák meghatározása

A lekérdezés-optimalizáló által a lekérdezés fordításakor használt statisztikai objektumokat egy becsült vagy tényleges végrehajtási terv vizsgálatával találja meg. A végrehajtási terv vizsgálatakor a OptimizerStatsUage elem StatisticsInfo elemeket tartalmaz, amelyek a lekérdezésoptimalizáló által a fordítás során betöltött statisztikai objektumokra vonatkozó információkat tartalmazzák. Az StatisticsInfo elemek tartalmazzák a statisztikai objektum nevét, az adatbázist, a sémát és a táblázatot, amelyhez tartozik, a módosítás számát a fordításkor, a mintavételezési százalékot és az utolsó frissítés időpontját.

A végrehajtási terv vizsgálatához használja az alábbi technikákat:

  • A SQL Server Management Studio válassza a Tényleges végrehajtási terv belefoglalása (Ctrl+M) lehetőséget a lekérdezés futtatása előtt. Az eredményekkel együtt megjelenő Végrehajtási terv lapon a következőt teheti:
    • Kattintson a jobb gombbal a grafikus tervre, és válassza a Végrehajtási terv XML-fájljának megjelenítése lehetőséget. Keresse meg a(z) OptimizerStatsUsage elemet és annak minden StatisticsInfo gyermekelemét.
    • Válassza ki a végső (bal oldali) operátort. (SELECT lekérdezés esetén ez az operátor egy SELECT csomópont.) A Tulajdonságok ablakban bontsa ki a OptimizerStatsUsage csomópontot, és tekintse meg a lekérdezésben használt statisztikai objektumokra vonatkozó információkat.
  • Futtassa SETSET STATISTICS XML az ON parancsot a lekérdezés előtt. Válassza ki az eredményekkel együtt megjelenő hivatkozást a végrehajtási terv XML-fájljának megtekintéséhez.
  • A legutóbbi lekérdezésekhez kérdezze le a(z) sys.dm_exec_query_plan vagy a(z) sys.dm_exec_query_statistics_xml elemet.
  • Olvasson be egy korábban rögzített tervet a Query Store-ból a sys.query_store_plan használatával.

Mindegyik StatisticsInfo elem a mintaadatbázis lekérdezésének következő XML-töredékéhez AdventureWorks2022 hasonlít:

<StatisticsInfo 
    Database="[AdventureWorks2022]" 
    Schema="[Sales]" 
    Table="[SalesOrderDetail]" 
    Statistics="[IX_SalesOrderDetail_ProductID]" 
    ModificationCount="0" 
    SamplingPercent="100" 
    LastUpdate="2025-09-07T15:32:16.89" />
Attribute Meaning
\, \, \ Az az objektum, amelyhez a statisztika tartozik.
Statistics Az adatbázisban található statisztikai objektum neve. Használja ezt a nevet a DBCC SHOW_STATISTICS vagy a sys.stats használatával a hisztogram és a sűrűségvektor megvizsgálásához.
ModificationCount A statisztika legutóbbi frissítése óta történt adatmódosítások száma a terv fordításának időpontjában. A táblázat méretéhez viszonyított nagy érték azt jelzi, hogy a statisztika elavult volt a fordítás során.
SamplingPercent A statisztikai adatok létrehozásához mintavételezett sorok százalékos aránya. Az alacsonyabb értékek kevésbé pontos hisztogramokat hozhatnak létre a ferde adatokhoz.
LastUpdate Az utolsó statisztikai frissítés időbélyege. Ha a AUTO_UPDATE_STATISTICS beállítás engedélyezve van az adatbázisban, az adatbázis szükség esetén automatikusan frissíti a statisztikákat.

Note

StatisticsInfo a terv összeállítása során rendelkezésre álló és figyelembe vett statisztikákat tükrözi. Ha hiányzik egy bejegyzés egy StatisticsInfo olyan oszlophoz, amelyre a lekérdezés szűr, a lekérdezésoptimalizáló nem azonosította a vonatkozó statisztikákat, ami a gyenge teljesítmény lehetséges forrása.

Egy statisztikai objektum frissességének és módosításainak aktuális számának ellenőrzéséhez használja a sys.dm_db_stats_properties. Az alábbi lekérdezés például a táblában IX_SalesOrderDetail_ProductIDelnevezett Sales.SalesOrderDetail statisztikai objektum aktuális metrikáit tartalmazza:

SELECT
    OBJECT_SCHEMA_NAME(s.object_id) AS schema_name,
    OBJECT_NAME(s.object_id)        AS table_name,
    s.name                          AS statistics_name,
    sp.last_updated,
    sp.rows,
    sp.rows_sampled,
    sp.modification_counter
FROM sys.stats AS s
OUTER APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) AS sp
WHERE s.object_id = OBJECT_ID(N'Sales.SalesOrderDetail')
  AND s.name = N'IX_SalesOrderDetail_ProductID';

Annak megállapításához, hogy az aktuális adatbázis automatikus statisztikáinak létrehozása és frissítése engedélyezve van-e, használja a következőt:

SELECT [name],
    is_auto_create_stats_on,
    is_auto_update_stats_on,
    is_auto_update_stats_async_on
FROM sys.databases
WHERE [name] = DB_NAME();

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. A problémák elkerülése érdekében kövesse a lekérdezéstervezési irányelveket a statisztikák hatékony használatához. 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 a helyzet a számosság optimálisnál rosszabb becsléséhez vezet, és ronthatja a lekérdezés teljesítményét. A hisztogramokkal kapcsolatos további információkért tekintse meg ebben a cikkben a histogram szakaszt, vagy a sys.dm_db_stats_histogram elemet.

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 az állandókat tartalmazó kifejezéseket. A Lekérdezésoptimalizáló nem értékeli ki az összes olyan függvényt és kifejezést, amely állandókat tartalmaz, mielőtt meghatározza a számosságbecsléseket. 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 Lekérdezésoptimalizáló nem ismeri a helyi változó értékét a lekérdezés-végrehajtási terv létrehozásakor. Amikor egy lekérdezés paramétert használ, a Lekérdezésoptimalizáló a tárolt eljárás által kapott 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öbbértékű táblaértékű függvények eredményeinek tárolásához. A Lekérdezésoptimalizáló nem hoz létre statisztikákat többértékű 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 kell-e használni. 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. A probléma elkerülése érdekében a tárolt eljárást az alábbiak szerint két eljárásra írhatja át:

    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éseinek javításához használja a OPTIMIZE FOR <value>OPTIMIZE FOR UNKNOWN lekérdezési tippeket a következővel RECOMPILE: . 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 további tippeket adhat meg, például USE PLANa lekérdezés viselkedésének szabályozásához, miközben az alkalmazás változásait vizsgálja az alkalmazás szállítójával. 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.

Kapcsolódó tartalom

  • Last updated on