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

Oszlopcentrikus indexek – lekérdezési teljesítmény

Vonatkozik a következőkre:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalitikai Platform System (PDW)SQL adatbázis a Microsoft Fabric-ben

Ez a cikk javaslatokat tartalmaz a gyors lekérdezési teljesítmény elérésére oszlopcentrikus indexekkel.

Az oszlopcentrikus indexek akár 100-szor jobb teljesítményt is elérhetnek az elemzési és adattárház-számítási feladatokon, és akár tízszer nagyobb adattömörítést is elérhetnek, mint a hagyományos sortárindexek. Ezek a javaslatok segítenek a lekérdezéseknek elérni azt a gyors lekérdezési teljesítményt, amelyet az oszlopcentrikus indexek úgy terveztek, hogy biztosítsanak.

Javaslatok a lekérdezési teljesítmény javítására

Az alábbiakban néhány javaslatot talál a nagy teljesítmény nyújtására tervezett oszlopalapú indexekkel kapcsolatban.

1. Az adatok rendszerezése, hogy a teljes táblavizsgálat során több sorcsoportot lehessen kizárni.

  • Gondosan válassza a beszúrási sorrendet. A hagyományos adattárházakban gyakran előfordul, hogy az adatok valóban időrendben lesznek beszúrva, az elemzés pedig idődimenzióban történik. Például az értékesítések negyedéves elemzése. Az ilyen típusú számítási feladatok esetében a sorcsoport eltávolítása automatikusan megtörténik. Az SQL Server 2016-ban (13.x) a lekérdezésfeldolgozás részeként kihagyott sorcsoportok számát meghatározhatja.

  • Használjon soralapú fürtözött indexet. Ha a gyakori lekérdezési predikátum a beszúrási sorrendtől független oszlopon (például C1) található, hozzon létre egy sorcentrikus fürtözött indexet a C1oszlopon. Ezután törölje a sorként tárolt csoportosított indexet, és hozzon létre egy oszlopalapú csoportosított indexet. Ha a fürtözött oszlopraktározott indexet kifejezetten a(z) MAXDOP = 1 használatával hozza létre, az eredményül kapott fürtözött oszlopraktározott index tökéletesen rendezve lesz az oszlop C1. Ha MAXDOP = 8ad meg, akkor nyolc sorcsoport értékeinek átfedése jelenik meg. Nem fürtözött columnstore index (NCCI) esetében, ha a tábla sor-alapú fürtözött indexet tartalmaz, a sorokat már a fürtözött indexkulcs alapján rendezi. Ebben az esetben a nem-clustered oszlopcentrikus index automatikusan is rendezve lesz. Az oszlopcentrikus indexek nem tartják meg a sorok sorrendjét. Az új sorok beszúrásakor vagy a régebbi sorok frissítésekor előfordulhat, hogy meg kell ismételnie a folyamatot, mivel az elemzési lekérdezés teljesítménye romlhat.

  • Táblaparticionálás implementálása. Particionálhatja az oszlopcentrikus indexet, majd partícióeliminálás használatával csökkentheti a vizsgálandó sorcsoportok számát. Egy ténytábla például az ügyfelek által végrehajtott vásárlásokat tárolja. Gyakori lekérdezési minta a negyedéves vásárlások megkeresése customeralapján. Ebben az esetben kombinálja a beszúrási sorrend oszlopot customer oszlop particionálásával. Minden partíció tartalmaz sorokat minden egyes customer-hoz, a beszúráskor való rendezéssel. Érdemes lehet táblaparticionálást is használni, ha el kell távolítania a régebbi adatokat az oszloptárból. A szükségtelen partíciók ki- és csonkolása hatékony stratégia az adatok töredezettség generálása nélküli törlésére.

  • Kerülje a nagy mennyiségű adat törlését. A tömörített sorok eltávolítása egy sorcsoportból nem szinkron művelet. Költséges lenne kibontani egy sorcsoportot, törölni a sort, majd újra összeadni. Ezért a tömörített sorcsoportok adatainak törlésekor ezek a sorcsoportok továbbra is be vannak vizsgálva, annak ellenére, hogy kevesebb sort adnak vissza. Ha több sorcsoport törölt sorainak száma elég nagy ahhoz, hogy kevesebb sorcsoportba egyesíthető legyen, az oszloptár átrendezése növeli az index minőségét, és a lekérdezési teljesítmény javul. Ha az adattörlési folyamat általában teljes sorcsoportokat ürít ki, fontolja meg a táblaparticionálás használatát. A sorok törlése helyett váltson ki olyan partíciókat, amelyekre már nincs szükség, és csonkítsa őket.

    Note

    Az SQL Server 2019-től (15.x) kezdődően a tupel-mozgatót egy háttérben futó egyesítési feladat segíti. Ez a feladat automatikusan tömöríti a belső küszöbérték által meghatározott kisebb OPEN delta sorcsoportokat, vagy egyesíti a tömörített sorcsoportokat, amelyekből nagy számú sor törölve lett. Ez idővel javítja az oszlopcentrikus index minőségét. Ha nagy mennyiségű adat törlése szükséges az oszlopcentrikus indexből, fontolja meg a művelet kisebb törlési kötegekre való felosztását. A kötegelés lehetővé teszi, hogy a háttéregyesítési feladat kezelje a kisebb sorcsoportok egyesítésének feladatát, és javítja az index minőségét. Ezután az adattörlés után nem kell ütemezni az index átszervezésének karbantartási időszakait. Az oszlopcentrikus kifejezésekről és fogalmakról további információt a Columnstore-indexek: áttekintés című témakörben talál.

2. Tervezze meg, hogy elegendő memória legyen az oszlopcentrikus indexek párhuzamos létrehozásához

Az oszlopcentrikus indexek létrehozása alapértelmezés szerint párhuzamos művelet, hacsak nincs korlátozva a memória. Az index párhuzamos létrehozása több memóriát igényel, mint az index soros létrehozása. Ha elegendő memória áll rendelkezésre, az oszlopalapú index létrehozása körülbelül 1,5-szer annyi ideig tart, mint egy B-fa felépítése ugyanazon oszlopokon.

Az oszlopcentrikus index létrehozásához szükséges memória az oszlopok számától, a sztringoszlopok számától, a párhuzamosság fokától (DOP) és az adatok jellemzőitől függ. Ha például a táblázat kevesebb mint egymillió sort tartalmaz, az adatbázismotor csak egy szálat használ az oszlopcentrikus index létrehozásához.

Ha a táblázat több mint egymillió sort tartalmaz, de az Adatbázismotor nem kap elég memória-hozzárendelést az index MAXDOP-pal való létrehozásához, az Adatbázismotor szükség szerint automatikusan csökkenti a MAXDOP értékét. Bizonyos esetekben a DOP-t egyre kell csökkenteni ahhoz, hogy az indexet a korlátozott memóriafeltételek mellett hozzák létre a rendelkezésre álló memóriajuttatásban.

Az SQL Server 2016 (13.x) óta a lekérdezés mindig kötegelt módban működik. A korábbi kiadásokban a kötegelt feldolgozás végrehajtása csak akkor történik, ha a DOP nagyobb, mint egy.

Az oszlopcentrikus teljesítmény magyarázata

Az oszlopcentrikus indexek nagy lekérdezési teljesítményt érnek el, ha a nagy sebességű memóriabeli kötegelt feldolgozást olyan technikákkal kombinálják, amelyek jelentősen csökkentik az I/O-követelményeket. Mivel az elemzési lekérdezések nagy számú sort vizsgálnak, általában I/O-kötöttek, ezért a lekérdezés végrehajtása során az I/O csökkentése kritikus fontosságú az oszlopcentrikus indexek tervezése szempontjából. Az adatok memóriába való beolvasása után kritikus fontosságú a memórián belüli műveletek számának csökkentése.

Az oszlopcentrikus indexek csökkentik az I/O-t, és nagy adattömörítéssel, oszlopkiküszöböléssel, sorcsoport-kiküszöböléssel és kötegelt feldolgozással optimalizálják a memóriabeli műveleteket.

Adattömörítés

Az oszlopcentrikus indexek akár 10-szer nagyobb adattömörítést is elérhetnek, mint a sortárindexek. Ez jelentősen csökkenti az elemzési lekérdezések végrehajtásához szükséges I/O-t, és ezáltal javítja a lekérdezési teljesítményt.

  • Az oszlopcentrikus indexek tömörített adatokat olvasnak a lemezről, ami azt jelenti, hogy kevesebb bájtnyi adatot kell beolvasni a memóriába.

  • Az oszlopalapú indexek tömörített formában tárolják az adatokat a memóriában, csökkentve ezzel az I/O műveleteket, elkerülve ugyanazon adatok ismételt beolvasását a memóriába. Például a 10-szeres tömörítéssel az oszlopcentrikus indexek tízszer több adatot tárolhatnak a memóriában, mint az adatok tömörítetlen formában való tárolásához képest. Ha több adat van a memóriában, valószínűbb, hogy az oszlopcentrikus index megkeresi a memóriában szükséges adatokat anélkül, hogy felesleges olvasások kellenek a lemezről.

  • Az oszlopcentrikus indexek sorok helyett oszlopok szerint tömörítik az adatokat, így nagy tömörítési arányt érnek el, és csökkentik a lemezen tárolt adatok méretét. Minden oszlopot külön tömörítünk és tárolunk. Az oszlopon belüli adatok mindig azonos adattípussal rendelkeznek, és általában hasonló értékekkel rendelkeznek. Az oszlopcentrikus adattömörítési technikák kiválóan alkalmasak a nagyobb tömörítési sebesség elérésére, ha az értékek hasonlóak.

A ténytábla például az ügyfelek címét tárolja, és tartalmaz egy oszlopot a country-regionszámára. A lehetséges értékek teljes száma kevesebb, mint 200. Ezen értékek némelyike többször ismétlődik. Ha a ténytábla 100 millió sorból áll, a country-region oszlop könnyen tömöríthető, és kevés tárhelyet igényel. A soronkénti tömörítés így nem tudja kihasználni az oszlopértékek hasonlóságát, és több bájtot kell használnia a country-region oszlop értékeinek tömörítéséhez.

Oszlopok eliminálása

Az oszlopcentrikus indexek kihagyják az olvasást olyan oszlopokban, amelyekre nem hivatkozik a lekérdezés. Az oszlopelimináció tovább csökkenti a lekérdezések végrehajtásához szükséges I/O-t, és ezáltal javítja a lekérdezés teljesítményét.

  • Az oszlopelivétel azért lehetséges, mert az adatok oszloponként rendezettek és tömörítve lesznek. Ezzel szemben, ha az adatokat sorról sorra tárolják, az egyes sorok oszlopértékei fizikailag együtt vannak tárolva, és nem lehet könnyen elválasztani őket. A lekérdezésfeldolgozónak egy teljes sorban kell olvasnia az adott oszlopértékek lekéréséhez, növelve az I/O értékét, mivel a további adatok szükségtelenül beolvashatók a memóriába.

Ha például egy tábla 50 oszlopot tartalmaz, és a lekérdezés csak öt oszlopot használ, az oszlopcentrikus index csak az öt oszlopot kéri le a lemezről. Kihagyja az olvasást a többi 45 oszlopban, és további 90%csökkenti az I/O-t, feltéve, hogy minden oszlop hasonló méretű. Ha ugyanazokat az adatokat egy sortárban tárolja, a lekérdezésfeldolgozónak be kell olvasnia a fennmaradó 45 oszlopot.

Sorcsoport megszüntetése

Teljes táblavizsgálatok esetén az adatok nagy része általában nem felel meg a lekérdezési predikátum feltételeinek. Metaadatok használatával az oszlopcentrikus index képes kihagyni az olvasást azokban a sorcsoportokban, amelyek nem tartalmazzák a lekérdezés eredményéhez szükséges adatokat, mindezt tényleges I/O nélkül. Ez a rowgroup-eltávolításnak nevezett képesség csökkenti az I/O-t a teljes táblavizsgálatokhoz, és ezáltal javítja a lekérdezési teljesítményt.

Mikor kell egy oszlopcentrikus indexnek teljes táblázatvizsgálatot végeznie?

Az SQL Server 2016-tól kezdődően (13.x) létrehozhat egy vagy több normál, nem klaszterezett soradatbázis vagy B-tree indexet egy fürtözött oszlopalapú indexen. A nem rendezett B-fa indexek felgyorsíthatják az egyenlőségi predikátummal vagy egy kis értéktartományú predikátummal rendelkező lekérdezéseket. Bonyolultabb predikátumok esetén a lekérdezésoptimalizáló teljes táblavizsgálatot választhat. A sorcsoportok kihagyása nélkül a teljes táblázatvizsgálat időigényes lehet, különösen a nagy méretű táblák esetében.

Mikor előnyös egy elemzési lekérdezés a sorcsoport kihagyásának kihasználására egy teljes táblázat átvizsgálása során?

Egy kiskereskedelmi üzlet például egy csoportosított oszlopcentrikus indexet tartalmazó ténytáblával modellezi az értékesítési adatait. Minden új értékesítés a tranzakció különböző attribútumait tárolja, beleértve a termék értékesítésének dátumát is. Érdekes, hogy bár az oszlopcentrikus indexek nem garantálják a rendezett sorrendet, a táblázat sorai dátum szerinti sorrendbe vannak betöltve. Idővel ez a táblázat növekszik. Bár a kiskereskedelmi üzlet megtarthatja az értékesítési adatokat az elmúlt 10 évben, előfordulhat, hogy egy elemzési lekérdezésnek csak az utolsó negyedév összesítését kell kiszámítania. Az oszlopcentrikus indexek kiküszöbölhetik az előző 39 negyedév adatainak elérését a dátumoszlop metaadatainak megtekintésével. Ez 97%-es csökkenés a memóriába beolvasott és feldolgozott adatok mennyiségében.

Mely sorcsoportokat hagyja ki a teljes táblázatvizsgálat?

Annak meghatározásához, hogy mely sorcsoportokat kell megszüntetni, az oszlopcentrikus index metaadatokkal tárolja az egyes sorcsoportok egyes oszlopszegmenseinek minimális és maximális értékeit. Ha az oszlopszegmens-tartományok egyike sem felel meg a lekérdezési predikátum feltételeinek, a rendszer kihagyja a teljes sorcsoportot anélkül, hogy tényleges I/O-t végezne. Ez azért működik, mert az adatok általában rendezett sorrendben vannak betöltve. Bár a sorrendezés nem garantált, a hasonló adatértékek gyakran ugyanabban a sorcsoportban vagy egy szomszédos sorcsoportban találhatók.

A sorcsoportokkal kapcsolatos további információkért tekintse meg az oszlopcentrikus index tervezési irányelveit.

Batch módú végrehajtás

Batch módú végrehajtás csoportok sorait dolgozza fel, általában egyszerre legfeljebb 900-at a hatékonyság növelése érdekében. A lekérdezés például SELECT SUM(Sales) FROM SalesData kiszámítja a SalesData táblából származó összes értékesítést. Kötegelt módban a lekérdezési motor 900 sorból álló csoportokban dolgozza fel az adatokat. Ez a módszer csökkenti a metaadat-hozzáférési költségeket és más típusú többletterheléseket azáltal, hogy azokat egy köteg összes sorában elosztja ahelyett, hogy az egyes sorok többletterhelését okozta. A köteg mód emellett lehetőség szerint tömörített adatokkal is működik, és eltávolítja a sor módban használt exchange-operátorok egy részét, ami jelentősen felgyorsítja az elemzési lekérdezéseket.

Nem minden egyes lekérdezés-végrehajtó operátor hajtható végre kötegelt módban. Az adatmanipulációs nyelv (DML) műveleteit, például a beszúrást, a törlést vagy a frissítést például egy sorban hajtja végre a rendszer. A Batch mód operátora, például a Beolvasás, a Csatlakozás, az Összesítés, a Rendezés és mások javíthatja a lekérdezési teljesítményt. Mivel az oszlopcentrikus index az SQL Server 2012-ben (11.x) lett bevezetve, folyamatos erőfeszítéseket kell tenni a köteg módban végrehajtható operátorok kibővítésére. Az alábbi táblázat azokat az operátorokat mutatja be, amelyek kötegelt módban futnak a termékverziónak megfelelően.

Batch mód operátorai Használatkor SQL Server 2012 (11.x) SQL Server 2014 (12.x) SQL Server 2016 (13.x) és SQL Database1 Comments
DML-műveletek (beszúrás, törlés, frissítés, egyesítés) no no no A kötegelt mód DML-vel való használatából származó teljesítményjavulás nem jelentős.
oszloptár index vizsgálat SCAN Nem elérhető yes yes Oszlopcentrikus indexek esetén leküldhetjük a predikátumot a SCAN csomópontra.
oszlopalapú index vizsgálat (nem klaszterezett) SCAN yes yes yes yes
indexkeresés Nem elérhető Nem elérhető no Keresési műveletet hajtunk végre egy nem klaszterezett B-fa indexen sor módban.
skaláris számítás Skaláris értékre kiértékelt kifejezés. yes yes yes Mint minden kötegelt módú operátor esetében, az adattípusra vonatkozóan is vannak korlátozások.
összefűzés UNION és UNION ALL no yes yes
szűrő Predikátumok alkalmazása yes yes yes
kivonategyezés Hash-alapú összesítő függvények, külső hash összekapcsolás, jobb hash összekapcsolás, bal hash összekapcsolás, jobb belső összekapcsolás, bal belső összekapcsolás yes yes yes Az összesítés korlátozásai: sztringek esetén nincs min/max. Az elérhető összesítési függvények a következők: összeg/darab/átlag/min/max.
Az illesztés korlátozásai: nem lehet eltérő típusú illesztéseket használni nem egész szám típusok esetén.
illesztés egyesítése no no no
többszálas lekérdezések yes yes yes
beágyazott hurkok no no no
MAXDOP 1 alatt futó egyszálas lekérdezések no no yes
egyszálú lekérdezések soros lekérdezési tervvel no no yes
rendez "Sorrend záradék SCAN segítségével oszlop-tár index." no no yes
felső rendezés no no yes
ablakfüggvény-összesítések Nem elérhető Nem elérhető yes Új operátor az SQL Server 2016-ban (13.x).

1 Az SQL Server 2016 (13.x), az SQL Database Premium szintjeire, az S3 és újabb standard szintekre, valamint az összes virtuális magszintre és az Elemzési platformrendszerre (PDW) vonatkozik

További információ: lekérdezésfeldolgozási architektúra útmutatója.

Összesítő leküldéses leküldés

Az összesítő számítások normál végrehajtási útvonala, amely lekéri a megfelelő sorokat a SCAN csomópontból, és kötegelt módban összesíti az értékeket. Bár ez jó teljesítményt nyújt, az SQL Server 2016-tól kezdve (13.x) az összesítő művelet leküldhető a SCAN csomópontra. Az aggregátumleküldés a Batch mód végrehajtásán felül nagyságrendekkel javítja az összesített számítások teljesítményét, feltéve, hogy teljesülnek a következő feltételek:

  • Az összesítések MIN, MAX, SUM, COUNT és COUNT(*).
  • Az összesítő operátornak a SCAN csomópont vagy egy GROUP BY-val rendelkező SCAN csomópont tetején kell lennie.
  • Ez az aggregátum nem különálló összesítés.
  • Az összesítő oszlop nem sztringoszlop.
  • Az összesítő oszlop nem virtuális oszlop.
  • A bemeneti és kimeneti adattípusnak az alábbiak egyikének kell lennie, és 64 biten belül kell elférnie:
    • tinyint, int, bigint, smallint, bit
    • kispénz, pénz, decimális és numerikus pontosságú <= 18
    • kisdátum, dátum, dátum és idő, dátum és idő2, idő

Az összesítő leküldés például a következő lekérdezésekben történik meg:

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

Karakterlánc predikátum továbbítása

Adattárház-séma tervezésekor az ajánlott sémamodellezés egy vagy több ténytáblából és több dimenziótáblából álló csillagséma vagy hópehelyséma használata.

Tip

A ténytábla tárolja az üzleti méréseket vagy tranzakciókat, és dimenziótáblát, tárolja azokat a dimenziókat, amelyeken a tényeket elemezni kell. A dimenziómodellezésről további információért látogasson el a(z) Dimenziómodellezés a Microsoft Fabricszakaszhoz.

Tény lehet például egy rekord, amely egy adott régióban egy adott termék értékesítését jelzi, míg a dimenzió régiók, termékek stb. halmazát jelöli. A tény- és dimenziótáblák elsődleges/idegen kulcskapcsolaton keresztül kapcsolódnak egymáshoz. A leggyakrabban használt elemzési lekérdezések egy vagy több dimenziótáblát csatlakoztatnak a ténytáblához.

Tekintsünk egy dimenziótáblát Products. Egy tipikus elsődleges kulcs ProductCode, amely általában sztringként jelenik meg. A lekérdezések teljesítményéhez ajánlott helyettesítő kulcsot létrehozni, amely általában egy egész szám oszlop, amely a ténytáblából a dimenziótábla sorára hivatkozik.

Az oszlopcentrikus index hatékonyan futtat elemzési lekérdezéseket numerikus vagy egész számokon alapuló kulcsokat tartalmazó illesztésekkel és predikátumokkal. Az SQL Server 2016 (13.x) jelentősen javította a sztringalapú oszlopokkal rendelkező elemzési lekérdezések teljesítményét azáltal, hogy a sztringoszlopokat tartalmazó predikátumokat leküldi a SCAN csomópontra.

A karakterlánc predikátum leküldése az oszlopokhoz létrehozott elsődleges/másodlagos szótárat használja a lekérdezési teljesítmény javítása érdekében. Vegyük például egy 100 különböző sztringértékből álló sorcsoport sztringoszlop-szegmensét. A különböző sztringértékekre átlagosan 10 000-szer hivatkozunk, egymillió sort feltételezve. A sztring predikátum leküldése során a lekérdezés végrehajtása kiszámítja a predikátumot a szótár értékeivel szemben. Ha a predikátum megfelel, a rendszer automatikusan minősíti a szótárértékre hivatkozó összes sort. Ez kétféleképpen javítja a teljesítményt:

  • Csak a minősített sor lesz visszaadva, csökkentve azoknak a soroknak a számát, amelyeknek ki kell haladnia a vizsgálati csomópontból.
  • A karakterlánc-összehasonlítások száma csökken. Ebben a példában csak 100 karakterlánc-összehasonlításra van szükség az 1 millió összehasonlításhoz képest. Vannak bizonyos korlátozások:
    • Nincs karakterlánc predikátum optimalizálás a delta sorcsoportokhoz. A delta sorcsoportok oszlopaihoz nincs szótár.
    • Nincs sztring predikátum leküldés, ha a szótár bejegyzései meghaladják a 64 KB-ot.
    • A null értékeket kiértékelő kifejezés nem támogatott.

Szegmens megszüntetése

Az adattípus-választási lehetőségek jelentős hatással lehetnek a lekérdezési teljesítményen alapuló gyakori szűrési predikátumokra az oszlopcentrikus index lekérdezései esetében.

Az oszlopcentrikus adatokban a sorcsoportok oszlopszegmensekből állnak. Az egyes szegmensek metaadatai lehetővé teszik a szegmensek gyors eltávolítását olvasás nélkül. Ez a szegmenskivezetés numerikus, dátum- és időadattípusokra vonatkozik, és a datetimeoffset adattípusra, amelynek mérete kisebb vagy egyenlő kettőnél. Az SQL Server 2022 -től kezdve (16.x) a szegmensek megszüntetése a sztringre, a bináris, a guid adattípusokra és a datetimeoffset adattípusra terjed ki a kettőnél nagyobb skálázáshoz.

Az SQL Server azon verziójára való frissítés után, amely támogatja a sztringek minimális/maximális szegmensének eltávolítását (SQL Server 2022 (16.x) és újabb verziók), az oszlopcentrikus index csak akkor élvezheti ezt az előnyt, ha ALTER INDEX REBUILD vagy CREATE INDEX WITH (DROP_EXISTING = ON)használatával újraépítik.

A szegmensek megszüntetése nem vonatkozik a LOB-adattípusokra, például a (maximális) adattípus-hosszokra.

Jelenleg csak az SQL Server 2022 (16.x) és újabb verziók támogatják a fürtözött oszlop-adattároló sorcsoportok kizárását a LIKE predikátumok előtagja esetében, például column LIKE 'string%'. A szegmensek megszüntetése nem támogatott a LIKEelőtag nélküli használata esetén, például column LIKE '%string'.

Az oszloptárolós indexek a szegmenskiküszöbölést is kihasználják, különösen a szöveg típusú oszlopok esetében. Rendezett oszlopcentrikus indexek esetén az indexkulcs első oszlopában a szegmensek megszüntetése a leghatékonyabb, mert rendezve van. A tábla más oszlopaiban a szegmensek megszüntetése miatti teljesítménynövekedés kevésbé kiszámítható. A rendezett oszlopcentrikus indexekre vonatkozó további információkért lásd: Rendezett oszlopcentrikus index használata nagyméretű adattárháztáblákhoz. A rendezett oszlopstore index elérhetőségéről a Rendezett oszlopindex elérhetőségecímen található további információ.

A SET STATISTICS IOlekérdezési beállításával működés közben tekintheti meg a szegmensek eltávolítását. Keresse meg a következőhöz hasonló kimenetet, amely azt jelzi, hogy a szegmens megszüntetése megtörtént. A sorcsoportok oszlopszegmensből állnak, ezért ez a szegmensek eltávolítását jelezheti. Az alábbi SET STATISTICS IO lekérdezés kimeneti példája szerint a lekérdezés körülbelül 83% adatot hagyott ki:

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

Kapcsolódó tartalom

  • Last updated on