SQLShack

ez a cikk példákkal ismerteti az SQL Server nem fürtözött indexét.

Bevezetés

az SQL Server fürtözött indexeinek áttekintése című előző cikkben az index és a fürtözött indexek követelményét vizsgáltuk az SQL Server rendszerben.

mielőtt folytatnánk, vessünk egy gyors összefoglalót az SQL Server fürtözött indexéről:

• fizikailag rendezi az adatokat a fürtözött indexkulcs szerint
• táblázatonként csak egy fürtözött indexünk lehet
• a fürtözött index nélküli táblázat egy halom, ami teljesítményproblémákhoz vezethet
• az SQL Server automatikusan fürtözött indexet hoz létre az elsődleges kulcs oszlophoz
• a fürtözött indexet a az index b-fa formátumban van tárolva, és a leaf csomópont adatoldalait tartalmazza, az alábbiak szerint

nem fürtözött indexek a lekérdezés teljesítményéhez és optimalizálásához is hasznosak, a lekérdezés munkaterhelésétől függően. Ebben a cikkben vizsgáljuk meg a nem fürtözött indexet és annak belső elemeit.

az SQL Server nem fürtözött indexének áttekintése

nem fürtözött index esetén a leaf csomópont nem tartalmazza a tényleges adatokat. A tényleges adatok mutatójából áll.

• ha a táblázat fürtözött indexet tartalmaz, a levélcsomópont a fürtözött index adatoldalára mutat, amely tényleges adatokból áll
• ha a táblázat halom (fürtözött index nélkül), a levélcsomópont a halom oldalra mutat

az alábbi képen megnézhetjük a nem fürtözött index levélszintjét, amely a fürtözött index adatoldala felé mutat:

több nem fürtözött indexünk is lehet az SQL táblákban, mert ez egy logikai index, és fizikailag nem rendezi az adatokat a fürtözött indexhez képest.

értsük meg az SQL Server nem fürtözött indexét egy példa segítségével.

• hozzon létre egy alkalmazotti táblát index nélkül

  1 2 3 4 5 6

  Táblázat létrehozása dbo.Alkalmazott (EmpID INT, EMpName VARCHAR(50), EmpAge INT, Empkapcsolat VARCHAR szám(10) );

• helyezzen be néhány rekordot

  1 2 3

  helyezze be az alkalmazottak értékeit(1, ‘Raj’,32,8474563217) illessze be a munkavállalói értékeket(2, ‘kusum’,30,9874563210) helyezze be az alkalmazottak értékeit(3, ‘Akshita’,28,9632547120)

• keresse meg az EmpID 2-t, és keresse meg annak tényleges végrehajtási tervét

  1	válasszon * alkalmazottból, ahol EmpID=2

  ez nem egy tábla scan, mert nincs index ezen az asztalon:

  

  

• hozzon létre egy egyedi fürtözött indexet az EmpID oszlopban

  1	hozzon létre egyedi fürtözött INDEX IX_Clustered_Empployee a dbo.Alkalmazott (EmpID);

• keresse meg az EmpID 2-t, és keresse meg annak tényleges végrehajtási tervét

ebben a végrehajtási tervben észrevehetjük, hogy a táblázatvizsgálat fürtözött indexkeresésre változik:

hajtsunk végre egy másik SQL lekérdezést egy adott kapcsolattartó számmal rendelkező alkalmazott keresésére:

nincs indexünk az EmpContactNumber oszlopban, ezért a Query Optimizer a fürtözött indexet használja, de az egész indexet beolvassa a rekord lekéréséhez:

kattintson a jobb gombbal a végrehajtási tervre, majd válassza a végrehajtási terv XML megjelenítése lehetőséget:

megnyitja az XML végrehajtási tervet az új lekérdezési ablakban. Itt észrevesszük, hogy a fürtözött indexkulcsot használja, és beolvassa az egyes sorokat az eredmény lekéréséhez:

illesszünk be még néhány rekordot az alkalmazott táblába a következő parancsfájl használatával:

ebben a táblázatban hat alkalmazott adatai vannak. Most hajtsa végre újra a select utasítást az alkalmazotti rekordok lekéréséhez egy adott kapcsolattartási számmal:

a megadott feltétel alapján ismét mind a hat sort ellenőrzi az eredményért. Képzeld el, hogy több millió rekord van a táblázatban. Ha az SQL Server-nek el kell olvasnia az összes indexkulcs sort, az erőforrás-és időigényes feladat lenne.

a fürtözött indexet (nem a tényleges ábrázolást) a B-fa formátumban ábrázolhatjuk a következő kép szerint:

az előző lekérdezésben az SQL Server beolvassa a gyökércsomópont lapját, és lekéri az egyes levélcsomópontok lapjait és sorait az adatok visszakereséséhez.

most hozzunk létre egy egyedi, nem fürtözött indexet az SQL Server alkalmazásban az Empcontactnumber oszlop alkalmazott tábláján indexkulcsként:

mielőtt elmagyaráznánk ezt az indexet, futtassa újra a SELECT utasítást, majd tekintse meg a tényleges végrehajtási tervet:

ebben a végrehajtási tervben két összetevőt láthatunk:

• Indexkeresés (nem Klaszterezett)
• kulcskeresés (fürtözött)

ezen összetevők megértéséhez meg kell vizsgálnunk egy nem fürtözött indexet az SQL Server tervezésében. Itt láthatja, hogy a levélcsomópont tartalmazza a nem fürtözött indexkulcsot (EmpContactNumber) és a fürtözött indexkulcsot (EmpID):

most, ha a SELECT utasítást újra futtatja, a nem fürtözött indexkulccsal halad át, és egy fürtözött indexkulccsal rendelkező oldalra mutat:

azt mutatja, hogy a rekordot fürtözött indexkulcs és nem fürtözött indexkulcs kombinációjával tölti le. A SELECT utasítás teljes logikáját az alábbiak szerint láthatja:

1. a felhasználó végrehajtja a select utasítást, hogy megtalálja a megadott kapcsolattartó számmal egyező alkalmazotti rekordokat
2. a Lekérdezésoptimalizáló nem fürtözött indexkulcsot használ, és megtudja az oldalszámot 1001
3. ez az oldal fürtözött indexkulcsból áll. Az EmpID 1 A fenti képen látható
4. az SQL Server megtudja a 101.oldalt, amely EmpID 1 rekordokból áll, a fürtözött indexkulcs használatával
5. beolvassa a megfelelő sort, és visszaadja a kimenetet a felhasználónak

korábban láttuk, hogy hat sort olvas fel a megfelelő sor lekéréséhez, és egy sort ad vissza a kimenetben. Nézzünk meg egy végrehajtási tervet a nem fürtözött index használatával:

nem egyedi, nem fürtözött index az SQL Server alkalmazásban

több nem fürtözött indexünk is lehet egy SQL táblában. Korábban létrehoztunk egy egyedi, nem fürtözött indexet az EmpContactNumber oszlopban.

az index létrehozása előtt hajtsa végre a következő lekérdezést, hogy az EmpAge oszlopban duplikált érték legyen:

hajtsuk végre a következő lekérdezést egy nem egyedi, nem fürtözött indexhez. A lekérdezés szintaxisában nem adunk meg egyedi kulcsszót, hanem azt mondja az SQL Server-nek, hogy hozzon létre egy nem egyedi indexet:

mint tudjuk, az index kulcsának egyedinek kell lennie. Ebben az esetben nem egyedi kulcsot szeretnénk hozzáadni. Felmerül a kérdés: hogyan teszi az SQL Server ezt a kulcsot egyedivé?

az SQL Server a következőket teszi hozzá:

• hozzáadja a fürtözött indexkulcsot a nem egyedi nem fürtözött index levél és nem levél lapjaihoz
• ha a fürtözött indexkulcs szintén nem egyedi, akkor hozzáad egy 4 bájtos egyediesítőt, hogy az indexkulcs egyedi legyen

nem kulcsos oszlopok felvétele az SQL Server nem fürtözött indexébe

nézzük meg újra a következő lekérdezés következő tényleges végrehajtási tervét:

indexkeresést és kulcskeresési operátorokat tartalmaz, amint az a fenti képen látható:

1. az index keresi: Az SQL Query Optimizer indexkeresést használ a nem fürtözött indexen, és lekéri az EmpID, EmpContactNumber oszlopokat

2. ebben a lépésben a Query Optimizer kulcskeresést használ a fürtözött indexen, és lekéri az EmpName és EmpAge oszlopok értékeit

   

   

3. ebben a lépésben a Query Optimizer a nem fürtözött index minden egyes sorának beágyazott hurkait használja a fürtözött index sorhoz való illesztéshez

   

   

a beágyazott hurok költséges operátor lehet A nagy táblák számára. Csökkenthetjük a költségeket a nem fürtözött index nem kulcs oszlopok használatával. A nem Kulcs oszlopot a nem fürtözött indexben az index záradék segítségével adjuk meg.

dobjuk el és hozzuk létre a nem fürtözött indexet az SQL Server-ben a mellékelt oszlopok segítségével:

a mellékelt oszlopok az indexfa levélcsomópontjának részét képezik. Segít az adatok lekérésében az indexből, ahelyett, hogy tovább haladna az adatok visszakereséséhez.

a következő képen mind az EmpName, mind az EmpAge oszlopokat megkapjuk a levélcsomópont részeként:

hajtsa végre újra a SELECT utasítást, és tekintse meg a tényleges végrehajtási tervet. Ebben a végrehajtási tervben nincs kulcskeresés és beágyazott hurok:

mutassuk a kurzort az indexkeresés fölé, és nézzük meg a kimeneti oszlopok listáját. Az SQL Server az összes oszlopot megtalálja ezzel a nem fürtözött indexkereséssel:

a lekérdezés teljesítményét a fedőindex segítségével javíthatjuk a mellékelt nem kulcs oszlopok segítségével. Ez azonban nem azt jelenti, hogy az index definíciójában minden nem Kulcs oszlopnak kell lennie. Óvatosnak kell lennünk az index tervezésében, és tesztelnünk kell az index viselkedését a termelési környezetben történő telepítés előtt.

következtetés

ebben a cikkben az SQL Server nem fürtözött indexét és annak használatát a fürtözött indexszel kombinálva vizsgáltuk. Gondosan meg kell terveznünk az indexet a munkaterhelés és a lekérdezési viselkedés szerint.

• szerző
• Legutóbbi hozzászólások

mint egy MCSA certified és a Microsoft Certified Trainer Gurgaon, India, 13 éves tapasztalattal, Rajendra dolgozik a különböző nagyvállalatok összpontosítva teljesítmény optimalizálás, monitoring, magas rendelkezésre állás, és katasztrófa-helyreállítási stratégiák és végrehajtása. Több száz hiteles cikk szerzője az SQL Server, az Azure, a MySQL, a Linux, a Power BI, a Performance tuning, az AWS/Amazon RDS, a Git és a kapcsolódó technológiák területén, amelyeket eddig több mint 10 millió olvasó nézett meg.
az egyik legnagyobb ingyenes online cikkgyűjtemény megalkotója egyetlen témában, az SQL Server Always On Availability Groups című 50 részes sorozatával. Az SQL Server közösséghez való hozzájárulása alapján számos díjjal ismerték el, köztük a rangos “az év legjobb szerzője” 2020-ban és 2021-ben folyamatosan az SQLShack-en.
Raj mindig érdeklődik az új kihívások iránt, így ha tanácsadói segítségre van szüksége az írásaiban szereplő bármely témában, el lehet érni rajendrában.gupta16 @ gmail.com
Rajendra Gupta összes hozzászólásának megtekintése

Rajendra Gupta legújabb hozzászólásai (az összes megtekintése)

• ARM sablonok használata az Azure konténerpéldányok telepítéséhez SQL Server Linux képekkel – December 21, 2021
• Távoli asztali hozzáférés AWS RDS SQL Server számára Amazon RDS Custom-December 14, 2021
• az SQL Server fájlok tárolása az Azure Konténerpéldányok állandó tárolójában-December 10, 2021