Viens no svarīgākajiem veidiem, kā sasniegt augsta veiktspēja SQL serveris ir indeksu izmantošana. Indekss paātrina vaicājuma procesu, nodrošinot ātra piekļuve uz datu rindām tabulā, līdzīgi kā rādītājs grāmatā palīdz ātri atrast vajadzīgo informāciju. Šajā rakstā es sniegšu īss apskats indeksi iekšā SQL serveris un paskaidrojiet, kā tie ir sakārtoti datu bāzē un kā tie palīdz paātrināt datu bāzes vaicājumus.

Indeksi tiek veidoti tabulas un skata kolonnās. Indeksi nodrošina veidu, kā ātri meklēt datus, pamatojoties uz vērtībām šajās kolonnās. Piemēram, ja izveidojat indeksu primārajai atslēgai un pēc tam meklējat datu rindu, izmantojot primārās atslēgas vērtības, SQL serveris vispirms atradīs indeksa vērtību un pēc tam izmantos indeksu, lai ātri atrastu visu datu rindu. Bez indeksa tiks veikta visu tabulas rindu pilnīga skenēšana, kas var būtiski ietekmēt veiktspēju.
Varat izveidot indeksu lielākajā daļā tabulas vai skata kolonnu. Izņēmums galvenokārt ir kolonnas ar datu tipiem lielu objektu glabāšanai ( LOB), piemēram, attēlu, tekstu vai varchar (maks.). Varat arī izveidot indeksus kolonnās, kas paredzētas datu glabāšanai formātā XML, taču šie indeksi ir strukturēti nedaudz savādāk nekā standarta indeksi, un to izskatīšana ir ārpus šī raksta darbības jomas. Arī rakstā nav runāts kolonnu veikals indeksi. Tā vietā es koncentrējos uz tiem indeksiem, kas visbiežāk tiek izmantoti datu bāzēs SQL serveris.
Rādītājs sastāv no lapu kopas, indeksa mezgliem, kas ir sakārtoti koka struktūrā - līdzsvarots koks. Šai struktūrai ir hierarhisks raksturs, un tā sākas ar saknes mezglu hierarhijas augšpusē un lapu mezgliem, lapām, apakšā, kā parādīts attēlā:


Kad veicat vaicājumu indeksētā kolonnā, vaicājuma programma sākas saknes mezgla augšdaļā un virzās uz leju caur starpmezgliem, un katrs starpslānis satur detalizētāku informāciju par datiem. Vaicājumu dzinējs turpina pārvietoties pa indeksa mezgliem, līdz tas sasniedz zemāko līmeni ar indeksa lapām. Piemēram, ja indeksētā kolonnā meklējat vērtību 123, vaicājumu programma vispirms noteiks lapu pirmajā vidējā līmenī saknes līmenī. Šajā gadījumā pirmā lapa norāda uz vērtību no 1 līdz 100, bet otrā no 101 līdz 200, tāpēc vaicājumu programma piekļūs šī vidējā līmeņa otrajai lapai. Tālāk jūs redzēsiet, ka jums vajadzētu atvērt nākamā vidējā līmeņa trešo lapu. No šejienes vaicājumu apakšsistēma nolasīs paša indeksa vērtību zemākā līmenī. Indeksa lapās var būt vai nu pašu tabulas dati, vai vienkārši rādītājs uz rindām ar datiem tabulā atkarībā no indeksa veida: grupēts indekss vai negrupēts indekss.

Klasterizēts indekss

Klasterizēts indekss saglabā faktiskās datu rindas indeksa lapās. Atgriežoties pie iepriekšējā piemēra, tas nozīmē, ka datu rinda, kas saistīta ar atslēgas vērtību 123, tiks saglabāta pašā indeksā. Svarīga īpašība Klasterizēts indekss ir tāds, ka visas vērtības tiek sakārtotas noteiktā secībā, augošā vai dilstošā secībā. Tāpēc tabulai vai skatam var būt tikai viens klasterizēts indekss. Turklāt jāņem vērā, ka dati tabulā tiek saglabāti sakārtotā veidā tikai tad, ja šajā tabulā ir izveidots klasterizēts indekss.
Tabulu, kurai nav grupēta indeksa, sauc par kaudzi.

Negrupēts indekss

Atšķirībā no kopu indeksa, negrupēta indeksa lapas satur tikai tās kolonnas ( taustiņu), pēc kura tiek noteikts šis indekss, un tajā ir arī rādītājs uz rindām ar reāliem datiem tabulā. Tas nozīmē, ka apakšvaicājumu sistēmai ir nepieciešama papildu darbība, lai atrastu un izgūtu nepieciešamos datus. Datu rādītāja saturs ir atkarīgs no tā, kā dati tiek glabāti: klasterizēta tabula vai kaudze. Ja rādītājs norāda uz grupētu tabulu, tas norāda uz grupētu indeksu, ko var izmantot faktisko datu atrašanai. Ja rādītājs norāda uz kaudzi, tas norāda uz konkrētu datu rindas identifikatoru. Negrupētus indeksus nevar kārtot kā grupētus indeksus, taču tabulā vai skatā varat izveidot vairāk nekā vienu negrupētu indeksu līdz 999. Tas nenozīmē, ka jums ir jāizveido pēc iespējas vairāk indeksu. Indeksi var uzlabot vai pasliktināt sistēmas veiktspēju. Papildus tam, ka varat izveidot vairākus negrupētus indeksus, varat iekļaut arī papildu kolonnas ( iekļauta kolonna) savā indeksā: indeksa lapās tiks saglabāta ne tikai pašu indeksēto kolonnu vērtība, bet arī šo neindeksēto papildu kolonnu vērtības. Šī pieeja ļaus jums apiet dažus indeksam noteiktos ierobežojumus. Piemēram, varat iekļaut neindeksējamu kolonnu vai apiet indeksa garuma ierobežojumu (vairumā gadījumu 900 baiti).

Indeksu veidi

Papildus tam, ka tas ir grupēts vai negrupēts indekss, to var tālāk konfigurēt kā saliktu indeksu, unikālu indeksu vai aptverošu indeksu.

Salikts indekss

Šādā rādītājā var būt vairāk nekā viena kolonna. Rādītājā varat iekļaut līdz 16 kolonnām, taču to kopējais garums ir ierobežots līdz 900 baitiem. Gan kopotie, gan negrupētie indeksi var būt salikti.

Unikāls indekss

Šis indekss nodrošina, ka katra vērtība indeksētajā kolonnā ir unikāla. Ja indekss ir salikts, unikalitāte attiecas uz visām indeksa kolonnām, bet ne uz katru atsevišķu kolonnu. Piemēram, ja kolonnās izveidojat unikālu indeksu VĀRDS Un UZVĀRDS, Tas pilnais vārds jābūt unikālam, taču ir iespējami vārda vai uzvārda dublikāti.
Unikāls indekss tiek automātiski izveidots, kad definējat kolonnas ierobežojumu: primāro atslēgu vai unikālo vērtību ierobežojumu:

• Primārā atslēga
  Kad definējat primārās atslēgas ierobežojumu vienai vai vairākām kolonnām, tad SQL serveris automātiski izveido unikālu klasterizētu indeksu, ja iepriekš nav izveidots klasterizēts indekss (šajā gadījumā primārajā atslēgā tiek izveidots unikāls negrupēts indekss)
• Vērtību unikalitāte
  Kad jūs definējat vērtību unikalitātes ierobežojumu, tad SQL serveris automātiski izveido unikālu negrupētu indeksu. Varat norādīt, ka tiek izveidots unikāls klasterizēts indekss, ja tabulā vēl nav izveidots klasterizēts indekss

Pārklājuma indekss

Šāds indekss ļauj konkrētam vaicājumam nekavējoties iegūt visus nepieciešamos datus no indeksa lapām bez papildu piekļuves pašas tabulas ierakstiem.

Indeksu projektēšana

Lai cik noderīgi būtu indeksi, tie ir rūpīgi jāizstrādā. Tā kā indeksi var aizņemt ievērojamu vietu diskā, jūs nevēlaties izveidot vairāk indeksu nekā nepieciešams. Turklāt indeksi tiek automātiski atjaunināti, kad tiek atjaunināta pati datu rinda, kas var izraisīt papildu resursu izmaksas un veiktspējas pasliktināšanos. Veidojot indeksus, jāņem vērā vairāki apsvērumi attiecībā uz datu bāzi un vaicājumiem pret to.

Datu bāze

Kā minēts iepriekš, indeksi var uzlabot sistēmas veiktspēju, jo tie nodrošina vaicājumu programmu ar ātru veidu, kā atrast datus. Tomēr jāņem vērā arī tas, cik bieži plānojat ievietot, atjaunināt vai dzēst datus. Mainot datus, ir jāmaina arī indeksi, lai atspoguļotu atbilstošās darbības ar datiem, kas var ievērojami samazināt sistēmas veiktspēju. Plānojot indeksēšanas stratēģiju, ņemiet vērā šādas vadlīnijas:

• Tabulām, kuras tiek bieži atjauninātas, izmantojiet pēc iespējas mazāk indeksu.
• Ja tabulā ir liels datu apjoms, bet izmaiņas ir nelielas, izmantojiet tik daudz indeksu, cik nepieciešams, lai uzlabotu savu vaicājumu veiktspēju. Tomēr rūpīgi pārdomājiet, pirms lietojat indeksus mazās tabulās, jo... Iespējams, ka indeksa meklēšanas izmantošana var aizņemt ilgāku laiku nekā visu rindu skenēšana.
• Klasterizētiem indeksiem mēģiniet saglabāt pēc iespējas īsākus laukus. Vislabākā pieeja ir izmantot kopu indeksu kolonnām, kurām ir unikālas vērtības un kuras nepieļauj NULL. Tāpēc primārā atslēga bieži tiek izmantota kā klasterizēts indekss.
• Kolonnas vērtību unikalitāte ietekmē indeksa veiktspēju. Kopumā, jo vairāk dublikātu jums ir kolonnā, jo sliktāka ir indeksa veiktspēja. No otras puses, jo vairāk ir unikālu vērtību, jo labāka ir indeksa veiktspēja. Kad vien iespējams, izmantojiet unikālu indeksu.
• Saliktam indeksam ņemiet vērā indeksa kolonnu secību. Izteiksmēs izmantotās kolonnas KUR(Piemēram, WHERE First Name = "Čārlijs") ir jābūt pirmajam rādītājā. Nākamās kolonnas ir jāuzskaita, pamatojoties uz to vērtību unikalitāti (slejas ar lielāko unikālo vērtību skaitu ir pirmās).
• Varat arī norādīt indeksu aprēķinātajām kolonnām, ja tās atbilst noteiktām prasībām. Piemēram, izteiksmēm, ko izmanto, lai iegūtu kolonnas vērtību, jābūt deterministiskām (vienmēr atgriež vienu un to pašu rezultātu noteiktai ievades parametru kopai).

Datu bāzes vaicājumi

Vēl viens apsvērums, veidojot indeksus, ir tas, kādi vaicājumi tiek izpildīti datu bāzē. Kā minēts iepriekš, jums jāapsver, cik bieži dati mainās. Turklāt ir jāizmanto šādi principi:

• Mēģiniet ievietot vai modificēt pēc iespējas vairāk rindu vienā vaicājumā, nevis darīt to vairākos atsevišķos vaicājumos.
• Izveidojiet negrupētu indeksu kolonnās, kuras bieži tiek izmantotas kā meklēšanas vienumi jūsu vaicājumos. KUR un savienojumi iekšā PIEVIENOJIES.
• Apsveriet iespēju indeksēt kolonnas, kas tiek izmantotas rindu meklēšanas vaicājumos, lai iegūtu precīzu vērtību atbilstību.

Un tagad patiesībā:

14 jautājumi par indeksiem pakalpojumā SQL Server, kurus jums bija neērti uzdot

Kāpēc tabulā nevar būt divi grupēti indeksi?

Vai vēlaties īsu atbildi? Klasterizēts indekss ir tabula. Kad tabulā izveidojat grupētu indeksu, krātuves programma sakārto visas tabulas rindas augošā vai dilstošā secībā atbilstoši indeksa definīcijai. Klasterizēts indekss nav atsevišķa vienība kā citi indeksi, bet gan mehānisms datu kārtošanai tabulā un ātras piekļuves datu rindām atvieglošanai.
Iedomāsimies, ka jums ir tabula ar pārdošanas darījumu vēsturi. Pārdošanas tabulā ir iekļauta tāda informācija kā pasūtījuma ID, preces pozīcija pasūtījumā, preces numurs, preces daudzums, pasūtījuma numurs un datums utt. Kolonnās izveidojat sagrupētu indeksu Pasūtījuma ID Un LineID, sakārtoti augošā secībā, kā parādīts tālāk T-SQL kods:
IZVEIDOT UNIKĀLU KLASTERĒTU INDEKSU ix_oriderid_lineid UZ dbo.Sales(Pasūtījuma ID, rindas ID);
Palaižot šo skriptu, visas tabulas rindas vispirms tiks fiziski sakārtotas pēc kolonnas OrderID un pēc tam pēc LineID, bet paši dati paliks vienā loģiskā blokā — tabulā. Šī iemesla dēļ nevar izveidot divus grupētus indeksus. Var būt tikai viena tabula ar vieniem datiem, un šo tabulu var kārtot tikai vienu reizi noteiktā secībā.

Ja kopu tabula sniedz daudzas priekšrocības, tad kāpēc izmantot kaudzi?

Tev taisnība. Klasterizētas tabulas ir lieliskas, un lielākā daļa jūsu vaicājumu darbosies labāk tabulās, kurām ir grupēts indekss. Bet dažos gadījumos var vēlēties atstāt galdus to dabiskajā, neskartajā stāvoklī, t.i. kaudzes veidā un izveidojiet tikai negrupētus indeksus, lai jūsu vaicājumi darbotos.
Kā jūs atceraties, kaudze saglabā datus nejaušā secībā. Parasti krātuves apakšsistēma pievieno datus tabulai tādā secībā, kādā tie tiek ievietoti, taču krātuves apakšsistēmai arī patīk pārvietot rindas, lai nodrošinātu efektīvāku glabāšanu. Tā rezultātā jums nav iespēju paredzēt, kādā secībā dati tiks saglabāti.
Ja vaicājumu programmai ir jāatrod dati, neizmantojot negrupēta indeksa priekšrocības, tā veiks pilnu tabulas skenēšanu, lai atrastu tai vajadzīgās rindas. Uz ļoti maziem galdiem tā parasti nav problēma, taču, kaudzes izmēram augot, veiktspēja ātri samazinās. Protams, var palīdzēt negrupēts indekss, izmantojot rādītāju uz failu, lapu un rindiņu, kurā tiek glabāti nepieciešamie dati - parasti tas ir daudz vairāk labākā alternatīva skenējot tabulu. Pat ja tā ir, ir grūti salīdzināt kopu indeksa priekšrocības, ņemot vērā vaicājuma veiktspēju.
Tomēr kaudze var palīdzēt uzlabot veiktspēju noteiktās situācijās. Apsveriet tabulu ar liela summa ievietošanas, bet ar neregulāru datu atjaunināšanu vai dzēšanu. Piemēram, tabula, kurā glabājas žurnāls, galvenokārt tiek izmantota, lai ievietotu vērtības, līdz tā tiek arhivēta. Kaudzē jūs neredzēsit peidžeru un datu sadrumstalotību, kā tas būtu ar kopu indeksu, jo rindas tiek vienkārši pievienotas kaudzes beigām. Pārāk liela lapu sadalīšana var būtiski ietekmēt veiktspēju, un tas nav labā nozīmē. Kopumā kaudze ļauj ievietot datus salīdzinoši nesāpīgi, un jums nebūs jārēķinās ar uzglabāšanas un uzturēšanas pieskaitāmajām izmaksām, kas būtu saistītas ar kopu indeksu.
Taču datu atjaunināšanas un dzēšanas trūkumu nevajadzētu uzskatīt par vienīgo iemeslu. Svarīgs faktors ir arī datu izlases veids. Piemēram, nevajadzētu izmantot kaudzi, ja bieži pieprasāt datu diapazonus vai vaicātie dati bieži ir jākārto vai jāgrupē.
Tas viss nozīmē, ka apsveriet kaudzes izmantošanu tikai tad, ja strādājat ar ļoti mazām tabulām vai visa jūsu mijiedarbība ar tabulu aprobežojas ar datu ievietošanu, un jūsu vaicājumi ir ārkārtīgi vienkārši (un jūs izmantojat negrupētus indeksus jebkurā gadījumā). Pretējā gadījumā izmantojiet labi izstrādātu klasterizētu indeksu, piemēram, tādu, kas definēts vienkāršā augošā atslēgas laukā, piemēram, plaši izmantota kolonna ar IDENTITĀTE.

Kā mainīt noklusējuma indeksa aizpildīšanas koeficientu?

Viena lieta ir mainīt noklusējuma indeksa aizpildījuma koeficientu. Cits jautājums ir saprast, kā darbojas noklusējuma attiecība. Bet vispirms speriet dažus soļus atpakaļ. Indeksa aizpildīšanas faktors nosaka vietas daudzumu lapā, lai saglabātu indeksu apakšējā līmenī (lapas līmenī) pirms aizpildīšanas. jauna lapa. Piemēram, ja koeficients ir iestatīts uz 90, tad indeksam pieaugot, tas aizņems 90% lapas un pēc tam pāries uz nākamo lapu.
Pēc noklusējuma indeksa aizpildīšanas faktora vērtība ir norādīta SQL serveris ir 0, kas ir tāds pats kā 100. Rezultātā visi jaunie indeksi automātiski pārmanto šo iestatījumu, ja vien savā kodā īpaši nenorādīsiet vērtību, kas atšķiras no sistēmas standarta vērtības, vai maināt noklusējuma darbību. Tu vari izmantot SQL Server Management Studio lai pielāgotu noklusējuma vērtību vai palaistu sistēmā saglabātu procedūru sp_configure. Piemēram, šāds komplekts T-SQL komandas iestata koeficienta vērtību uz 90 (vispirms jāpārslēdzas uz papildu iestatījumu režīmu):
EXEC sp_configure "rādīt papildu opcijas", 1; PĀRIET PĀRKONFIGURĒT; GO EXEC sp_configure "aizpildījuma koeficients", 90; PĀRIET PĀRKONFIGURĒT; AIZIET
Pēc indeksa aizpildīšanas faktora vērtības maiņas pakalpojums ir jārestartē SQL serveris. Tagad varat pārbaudīt iestatīto vērtību, palaižot sp_configure bez norādītā otrā argumenta:
EXEC sp_configure "aizpildījuma koeficients" GO
Šai komandai ir jāatgriež vērtība 90. Rezultātā visi jaunizveidotie indeksi izmantos šo vērtību. Varat to pārbaudīt, izveidojot indeksu un vaicājot aizpildījuma faktora vērtību:
IZMANTOT AdventureWorks2012; -- jūsu datu bāze GO CREATE NONCLUSTERED INDEX ix_cilvēki_uzvārds ON Person.Person(Uzvārds); GO SELECT fill_factor FROM sys.indexes WHERE objekts_id = objekta_id("Persona.Person") AND name = "ix_cilvēki_uzvārds";
IN šajā piemērā tabulā esam izveidojuši negrupētu indeksu Persona datu bāzē AdventureWorks2012. Pēc indeksa izveides mēs varam iegūt aizpildījuma faktora vērtību no sistēmas tabulām sys.indexes. Vaicājumam ir jāatgriež 90.
Tomēr iedomāsimies, ka indeksu izdzēsām un izveidojām vēlreiz, bet tagad norādījām konkrētu aizpildījuma faktora vērtību:
IZVEIDOT NEKLUSTERĒTU INDEKSU ix_cilvēki_uzvārds ON Person.Person(Uzvārds) WITH (fillfactor=80); GO SELECT fill_factor FROM sys.indexes WHERE objekts_id = objekta_id("Persona.Person") AND name = "ix_cilvēki_uzvārds";
Šoreiz esam pievienojuši norādījumus AR un opcija aizpildīšanas faktors mūsu indeksa izveides darbībai IZVEIDOT INDEKSU un norādīja vērtību 80. Operator ATLASĪT tagad atgriež atbilstošo vērtību.
Līdz šim viss ir bijis diezgan vienkārši. Visā šajā procesā jūs patiešām varat sadedzināt, ja izveidojat indeksu, kurā tiek izmantota noklusējuma koeficienta vērtība, pieņemot, ka jūs zināt šo vērtību. Piemēram, kāds ķeras pie servera iestatījumiem un ir tik spītīgs, ka iestata indeksa aizpildījuma koeficientu uz 20. Tikmēr jūs turpiniet veidot indeksus, pieņemot, ka noklusējuma vērtība ir 0. Diemžēl jūs nevarat uzzināt aizpildījumu. faktors, kamēr neizveidojat indeksu un pēc tam nepārbaudāt vērtību, kā to darījām savos piemēros. Pretējā gadījumā jums būs jāgaida brīdis, kad vaicājuma veiktspēja samazināsies tik daudz, ka jums sāks kaut ko aizdomāties.
Vēl viena problēma, kas jums jāzina, ir indeksu atjaunošana. Tāpat kā veidojot indeksu, indeksa aizpildīšanas faktora vērtību varat norādīt, kad to atjaunojat. Tomēr atšķirībā no komandas izveidot indeksu, rebuild neizmanto servera noklusējuma iestatījumus, neskatoties uz to, kā tas varētu šķist. Vēl jo vairāk, ja īpaši nenorāda indeksa aizpildījuma faktora vērtību, tad SQL serveris izmantos koeficienta vērtību, ar kādu šis indekss pastāvēja pirms tā pārstrukturēšanas. Piemēram, šāda darbība MAINĪT INDEKSU atjauno tikko izveidoto indeksu:
ALTER INDEX ix_cilvēki_uzvārds ON Person.Person REBUILD; GO SELECT fill_factor FROM sys.indexes WHERE objekts_id = objekta_id("Persona.Person") AND name = "ix_cilvēki_uzvārds";
Pārbaudot aizpildījuma faktora vērtību, mēs iegūsim vērtību 80, jo to mēs norādījām, kad pēdējo reizi izveidojām indeksu. Noklusējuma vērtība tiek ignorēta.
Kā redzat, indeksa aizpildījuma faktora vērtības maiņa nav tik sarežģīta. Ir daudz grūtāk zināt pašreizējo vērtību un saprast, kad tā tiek piemērota. Ja, veidojot un pārbūvējot indeksus, vienmēr konkrēti norādāt koeficientu, tad vienmēr zināt konkrēto rezultātu. Ja vien jums nav jāuztraucas par to, lai kāds cits vēlreiz nesabojātu servera iestatījumus, izraisot visu indeksu pārbūvi ar smieklīgi zemu indeksa aizpildīšanas koeficientu.

Vai ir iespējams izveidot grupētu indeksu kolonnai, kurā ir dublikāti?

Jā un nē. Jā, jūs varat izveidot grupētu indeksu atslēgas kolonnā, kurā ir dublētās vērtības. Nē, atslēgas kolonnas vērtība nevar palikt neunikālā stāvoklī. Ļauj man paskaidrot. Ja kolonnā izveidojat neunikālu klasterizētu indeksu, krātuves programma dublikātai vērtībai pievieno vienreizējo, lai nodrošinātu unikalitāti un tādējādi varētu identificēt katru klasterētās tabulas rindu.
Piemēram, varat izlemt izveidot klasterizētu indeksu kolonnā, kurā ir klienta dati Uzvārds uzvārda saglabāšana. Kolonnā ir vērtības Franklins, Henkoks, Vašingtona un Smits. Pēc tam vēlreiz ievietojat vērtības Adams, Hancock, Smith un Smith. Bet atslēgas kolonnas vērtībai ir jābūt unikālai, tāpēc uzglabāšanas dzinējs mainīs dublikātu vērtību, lai tie izskatītos apmēram šādi: Adams, Franklin, Hancock, Hancock1234, Washington, Smith, Smith4567 un Smith5678.
No pirmā acu uzmetiena šī pieeja šķiet laba, taču vesela skaitļa vērtība palielina atslēgas lielumu, kas var kļūt par problēmu, ja ir liels skaits dublikātu, un šīs vērtības kļūs par pamatu negrupētam indeksam vai svešam indeksam. galvenā atsauce. Šo iemeslu dēļ, kad vien iespējams, vienmēr jācenšas izveidot unikālus klasterizētus indeksus. Ja tas nav iespējams, tad vismaz mēģiniet izmantot kolonnas ar ļoti lielu unikālu vērtību saturu.

Kā tiek saglabāta tabula, ja nav izveidots klasterizēts indekss?

SQL serveris atbalsta divu veidu tabulas: grupētas tabulas, kurām ir grupēts indekss, un kaudzes tabulas vai tikai kaudzes. Atšķirībā no grupētajām tabulām, kaudzes dati netiek kārtoti nekādā veidā. Būtībā šī ir datu kaudze (kaudze). Ja pievienosiet rindu šādai tabulai, uzglabāšanas programma to vienkārši pievienos lapas beigām. Kad lapa ir aizpildīta ar datiem, tā tiks pievienota jaunai lapai. Vairumā gadījumu jūs vēlēsities tabulā izveidot grupētu indeksu, lai izmantotu kārtošanas iespējas un ātrākus vaicājumus (mēģiniet iedomāties, kā atrast telefona numurs adrešu grāmatā, kas nav sakārtota pēc neviena principa). Tomēr, ja izvēlaties neveidot grupētu indeksu, jūs joprojām varat izveidot negrupētu indeksu kaudzē. Šajā gadījumā katrā indeksa rindā būs rādītājs uz kaudzes rindu. Rādītājs ietver faila ID, lapas numuru un datu rindas numuru.

Kāda ir saistība starp vērtību unikalitātes ierobežojumiem un primāro atslēgu ar tabulas indeksiem?

Primārā atslēga un unikāls ierobežojums nodrošina, ka kolonnas vērtības ir unikālas. Tabulai var izveidot tikai vienu primāro atslēgu, un tajā nedrīkst būt vērtības NULL. Varat izveidot vairākus tabulas vērtības unikalitātes ierobežojumus, un katram no tiem var būt viens ieraksts ar NULL.
Kad veidojat primāro atslēgu, krātuves programma izveido arī unikālu klasterizētu indeksu, ja kopu indekss vēl nav izveidots. Tomēr jūs varat ignorēt noklusējuma darbību, un tiks izveidots nekopu indekss. Ja, veidojot primāro atslēgu, pastāv klasterizēts indekss, tiks izveidots unikāls negrupēts indekss.
Kad izveidojat unikālu ierobežojumu, krātuves programma izveido unikālu, negrupētu indeksu. Tomēr varat norādīt unikāla klasterizēta indeksa izveidi, ja tāds iepriekš nav izveidots.
Kopumā unikāls vērtības ierobežojums un unikāls indekss ir viens un tas pats.

Kāpēc grupētos un negrupētos indeksus SQL serverī sauc par B-koku?

SQL Server pamata indeksi, grupēti vai negrupēti, tiek sadalīti pa lapu kopām, ko sauc par indeksa mezgliem. Šīs lapas ir sakārtotas noteiktā hierarhijā ar koka struktūru, ko sauc par līdzsvarotu koku. Augšējā līmenī ir saknes mezgls, apakšā ir lapu mezgli ar starpmezgliem starp augšējo un apakšējo līmeni, kā parādīts attēlā:


Saknes mezgls nodrošina galveno ieejas punktu vaicājumiem, kas mēģina izgūt datus, izmantojot indeksu. Sākot no šī mezgla, vaicājumu apakšsistēma uzsāk pāreju hierarhiskā struktūra līdz atbilstošajam lapas mezglam, kurā ir dati.
Piemēram, iedomājieties, ka ir saņemts pieprasījums atlasīt rindas, kuru atslēgas vērtība ir 82. Vaicājuma apakšsistēma sāk darboties no saknes mezgla, kas attiecas uz piemērotu starpmezglu, mūsu gadījumā 1-100. No starpposma mezgla 1-100 notiek pāreja uz mezglu 51-100, un no tā uz gala mezglu 76-100. Ja tas ir klasterizēts indekss, tad mezgla lapā ir ar atslēgu saistītās rindas dati, kas ir vienādi ar 82. Ja tas ir negrupēts indekss, tad indeksa lapā ir rādītājs uz grupēto tabulu vai konkrētu rindu kaudze.

Kā indekss var pat uzlabot vaicājuma veiktspēju, ja jums ir jāšķērso visi šie indeksa mezgli?

Pirmkārt, indeksi ne vienmēr uzlabo veiktspēju. Pārāk daudz nepareizi izveidotu indeksu pārvērš sistēmu purvā un pasliktina vaicājuma veiktspēju. Precīzāk ir teikt, ka, ja indeksi tiek rūpīgi piemēroti, tie var nodrošināt ievērojamu veiktspējas pieaugumu.
Padomājiet par milzīgu grāmatu, kas veltīta veiktspējas regulēšanai SQL serveris(papīra versija, nevis elektroniskā versija). Iedomājieties, ka vēlaties atrast informāciju par Resource Governor konfigurēšanu. Varat vilkt ar pirkstu pa lappusei cauri visai grāmatai vai atvērt satura rādītāju un uzzināt precīzu lapas numuru ar meklēto informāciju (ja grāmata ir pareizi indeksēta un saturam ir pareizi rādītāji). Tas noteikti ietaupīs jūsu laiku, lai gan vispirms ir jāpiekļūst pavisam citai struktūrai (indeksam), lai iegūtu nepieciešamo informāciju no primārās struktūras (grāmatas).
Kā grāmatu rādītājs, rādītājs iekšā SQL serverisļauj izpildīt precīzus vaicājumus par nepieciešamajiem datiem, nevis pilnībā skenēt visus tabulā ietvertos datus. Mazām tabulām pilna skenēšana parasti nav problēma, taču lielas tabulas aizņem daudzas datu lapas, kas var izraisīt ievērojamu vaicājuma izpildes laiku, ja vien nepastāv rādītājs, kas ļauj vaicājuma programmai nekavējoties iegūt pareizo datu atrašanās vietu. Iedomājieties, ka apmaldāties daudzlīmeņu ceļu krustojumā lielas metropoles priekšā bez kartes, un jūs sapratīsit.

Ja indeksi ir tik lieliski, kāpēc gan neizveidot to katrā kolonnā?

Neviens labs darbs nedrīkst palikt nesodīts. Vismaz tā ir ar indeksiem. Protams, indeksi darbojas lieliski, ja vien palaižat operatora ieneses vaicājumus ATLASĪT, bet tiklīdz sākas bieža zvanīšana operatoriem IEVIETOT, ATJAUNINĀT Un DZĒST, tāpēc ainava mainās ļoti ātri.
Kad iniciējat operatora datu pieprasījumu ATLASĪT, vaicājumu dzinējs atrod indeksu, pārvietojas pa koka struktūru un atklāj meklētos datus. Kas var būt vienkāršāks? Bet lietas mainās, ja uzsākat paziņojumu par izmaiņām, piemēram, ATJAUNINĀT. Jā, priekšraksta pirmajai daļai vaicājumu programma atkal var izmantot indeksu, lai atrastu modificējamo rindu — tās ir labas ziņas. Un, ja rindā ir veiktas vienkāršas datu izmaiņas, kas neietekmē izmaiņas galvenajās kolonnās, tad izmaiņu process būs pilnīgi nesāpīgs. Bet ko darīt, ja izmaiņu rezultātā tiek sadalītas lapas, kurās ir dati, vai tiek mainīta atslēgas kolonnas vērtība, izraisot tās pārvietošanu uz citu indeksa mezglu — tā rezultātā indeksam, iespējams, būs nepieciešama reorganizācija, kas ietekmēs visus saistītos indeksus un darbības. , kā rezultātā strauji samazinās produktivitāte.
Līdzīgi procesi notiek, zvanot operatoram DZĒST. Rādītājs var palīdzēt atrast dzēšamos datus, taču pašu datu dzēšana var izraisīt lapas pārkārtošanu. Attiecībā uz operatoru IEVIETOT, visu indeksu galvenais ienaidnieks: jūs sākat pievienot lielu datu apjomu, kas noved pie izmaiņām indeksos un to reorganizācijā, un visi cieš.
Tāpēc apsveriet datubāzes vaicājumu veidus, domājot par to, kāda veida indeksus un cik daudz izveidot. Vairāk nenozīmē labāk. Pirms jauna indeksa pievienošanas tabulai ņemiet vērā ne tikai pamatā esošo vaicājumu izmaksas, bet arī patērētās diska vietas apjomu, funkcionalitātes un indeksu uzturēšanas izmaksas, kas var izraisīt domino efektu citās darbībās. Jūsu indeksa izveides stratēģija ir viens no svarīgākajiem ieviešanas aspektiem, un tajā jāiekļauj daudzi apsvērumi, sākot no indeksa lieluma, unikālo vērtību skaita un beidzot ar vaicājumu veidiem, ko rādītājs atbalstīs.

Vai kolonnā ar primāro atslēgu ir jāizveido klasterizēts indekss?

Varat izveidot grupētu indeksu jebkurā kolonnā, kas atbilst nepieciešamajiem nosacījumiem. Tā ir taisnība, ka klasterizēts indekss un primārās atslēgas ierobežojums ir izveidoti viens otram un atbilst debesīm, tāpēc saprotiet faktu, ka, izveidojot primāro atslēgu, tad automātiski tiks izveidots klasterizēts indekss, ja tāds nav bijis. izveidota iepriekš. Tomēr jūs varat izlemt, ka grupētais indekss citur darbosies labāk, un bieži vien jūsu lēmums būs pamatots.
Klasterizēta indeksa galvenais mērķis ir kārtot visas tabulas rindas, pamatojoties uz atslēgas kolonnu, kas norādīta, definējot indeksu. Tas nodrošina Ātrā meklēšana Un ērta piekļuve uz tabulas datiem.
Tabulas primārā atslēga var būt laba izvēle, jo tā unikāli identificē katru tabulas rindu, nepievienojot papildu datus. Dažos gadījumos labākā izvēle Būs surogātiskā primārā atslēga, kas ir ne tikai unikāla, bet arī maza izmēra un kuras vērtības palielinās secīgi, kas padara efektīvākus uz šīs vērtības balstītos negrupētos indeksus. Vaicājumu optimizētājam patīk arī šī klasterizētā indeksa un primārās atslēgas kombinācija, jo tabulu savienošana ir ātrāka nekā savienošana citā veidā, kurā netiek izmantota primārā atslēga un ar to saistītais klasterizētais indekss. Kā jau teicu, tas ir debesīs radīts mačs.
Visbeidzot, tomēr ir vērts atzīmēt, ka, veidojot klasterizētu indeksu, ir jāņem vērā vairāki aspekti: cik daudz neklasterētu indeksu būs uz tā pamata, cik bieži mainīsies galvenā indeksa kolonnas vērtība un cik liela. Ja mainās vērtības grupētā indeksa kolonnās vai indekss nedarbojas, kā paredzēts, var tikt ietekmēti visi pārējie tabulas indeksi. Klasterizētajam indeksam jābūt balstītam uz visnoturīgāko kolonnu, kuras vērtības palielinās noteiktā secībā, bet nemainās nejauši. Indeksam ir jāatbalsta vaicājumi pret tabulas visbiežāk piekļūtajiem datiem, lai vaicājumi pilnībā izmantotu to, ka dati tiek sakārtoti un pieejami saknes mezglos, indeksa lapās. Ja primārā atslēga atbilst šim scenārijam, izmantojiet to. Ja nē, izvēlieties citu kolonnu kopu.

Ko darīt, ja indeksējat skatu, vai tas joprojām ir skats?

Prezentācija ir virtuālais galds, kas ģenerē datus no vienas vai vairākām tabulām. Būtībā tas ir nosaukts vaicājums, kas izgūst datus no pamatā esošajām tabulām, kad vaicājat šajā skatā. Varat uzlabot vaicājuma veiktspēju, šajā skatā izveidojot grupētu indeksu un negrupētus indeksus, līdzīgi tam, kā veidojat indeksus tabulā, taču galvenais brīdinājums ir tāds, ka vispirms ir jāizveido klasterizēts indekss un pēc tam varat izveidot negrupētu indeksu.
Kad tiek izveidots indeksēts skats (materializēts skats), pati skata definīcija paliek atsevišķa vienība. Galu galā tas ir tikai iekodēts operators ATLASĪT, glabājas datu bāzē. Bet indekss ir pavisam cits stāsts. Izveidojot klasterizētu vai negrupētu indeksu pakalpojumu sniedzējam, dati tiek fiziski saglabāti diskā, tāpat kā parastais indekss. Turklāt, mainoties datiem pamatā esošajās tabulās, skata rādītājs automātiski mainās (tas nozīmē, ka, iespējams, vēlēsities izvairīties no skatu indeksēšanas tabulās, kas bieži mainās). Jebkurā gadījumā skats paliek skats - skats uz tabulām, bet precīzi izpildīts iekšā Šis brīdis, ar tam atbilstošiem indeksiem.
Lai skatā varētu izveidot indeksu, tam ir jāatbilst vairākiem ierobežojumiem. Piemēram, skats var atsaukties tikai uz bāzes tabulām, bet ne uz citiem skatiem, un šīm tabulām ir jāatrodas tajā pašā datu bāzē. Patiesībā ir daudz citu ierobežojumu, tāpēc noteikti pārbaudiet dokumentāciju SQL serveris par visām netīrajām detaļām.

Kāpēc izmantot aptverošu indeksu, nevis saliktu indeksu?

Pirmkārt, pārliecināsimies, ka mēs saprotam atšķirību starp abiem. Saliktais indekss ir vienkārši parasts indekss, kas satur vairāk nekā vienu kolonnu. Var izmantot vairākas atslēgu kolonnas, lai nodrošinātu, ka katra no tām ir unikāla tabulas rindas, iespējams, ka primārā atslēga sastāv no vairākām kolonnām, lai nodrošinātu tās unikalitāti, vai arī jūs mēģināt optimizēt bieži izsaukto vaicājumu izpildi vairākās kolonnās. Tomēr kopumā, jo vairāk galveno sleju indekss satur, jo mazāk efektīvs būs indekss, kas nozīmē, ka saliktie indeksi ir jāizmanto saprātīgi.
Kā minēts, vaicājums var gūt lielu labumu, ja visi nepieciešamie dati uzreiz atrodas indeksa lapās, tāpat kā pats rādītājs. Klasterizētam indeksam tā nav problēma, jo visi dati jau ir tur (tāpēc ir tik svarīgi rūpīgi pārdomāt, veidojot kopu indeksu). Bet lapu indeksā, kas nav grupēts, ir tikai galvenās kolonnas. Lai piekļūtu visiem pārējiem datiem, vaicājumu optimizētājam ir jāveic papildu darbības, kas var ievērojami palielināt vaicājumu izpildi.
Šeit palīgā nāk seguma indekss. Kad definējat negrupētu indeksu, galvenajām kolonnām varat norādīt papildu kolonnas. Piemēram, pieņemsim, ka jūsu lietojumprogramma bieži vaicā kolonnas datus Pasūtījuma ID Un Pasūtījuma datums tabulā Pārdošana:
SELECT OrderID, OrderDate FROM Sales WHERE OrderID = 12345;
Abās kolonnās varat izveidot saliktu, negrupētu indeksu, taču sleja OrderDate tikai pievienos indeksa uzturēšanas izmaksas, neizmantojot īpaši noderīgu atslēgu kolonnu. Labākais lēmums būtu izveidot aptverošu indeksu atslēgas kolonnā Pasūtījuma ID un papildus iekļauta kolonna Pasūtījuma datums:
IZVEIDOT NEKLUSTERĒTU INDEKSU ix_orderid UZ dbo.Pārdošana(Pasūtījuma ID) IEKĻAUTI (Pasūtījuma datums);
Tādējādi tiek novērsti lieko kolonnu indeksēšanas trūkumi, vienlaikus saglabājot priekšrocības, ko sniedz datu glabāšana lapās, izpildot vaicājumus. Iekļautā kolonna nav atslēgas daļa, bet dati tiek glabāti lapas mezglā, indeksa lapā. Tas var uzlabot vaicājuma veiktspēju bez papildu pieskaitāmām izmaksām. Turklāt uz aptverošajā indeksā iekļautajām kolonnām attiecas mazāk ierobežojumu nekā uz indeksa galvenajām kolonnām.

Vai dublikātu skaitam atslēgas kolonnā ir nozīme?

Kad veidojat indeksu, jums ir jācenšas samazināt dublikātu skaitu atslēgu kolonnās. Vai precīzāk: mēģiniet saglabāt pēc iespējas zemāku atkārtojumu skaitu.
Ja strādājat ar saliktu indeksu, dublēšana attiecas uz visām galvenajām kolonnām kopumā. Vienā kolonnā var būt daudz vērtību dublikātu, taču visās indeksa kolonnās ir jābūt minimālam atkārtojumam. Piemēram, kolonnās izveidojat saliktu negrupētu indeksu Vārds Un Uzvārds, jums var būt daudz John Doe vērtību un daudzas Stirna vērtības, taču vēlaties, lai būtu pēc iespējas mazāk John Doe vērtību vai vēlams tikai vienu John Doe vērtību.
Atslēgas kolonnas vērtību unikalitātes attiecību sauc par indeksa selektivitāti. Jo vairāk ir unikālu vērtību, jo augstāka ir selektivitāte: unikālajam indeksam ir vislielākā iespējamā selektivitāte. Vaicājumu programmai ļoti patīk kolonnas ar augstām selektivitātes vērtībām, it īpaši, ja šīs kolonnas ir iekļautas jūsu visbiežāk izpildīto vaicājumu WHERE klauzulās. Jo selektīvāks indekss, jo ātrāk vaicājumu programma var samazināt iegūtās datu kopas lielumu. Negatīvā puse, protams, ir tāda, ka kolonnas ar salīdzinoši nelielām unikālām vērtībām reti būs piemērotas indeksēšanai.

Vai ir iespējams izveidot negrupētu indeksu tikai noteiktai atslēgas kolonnas datu apakškopai?

Pēc noklusējuma negrupētajā indeksā ir viena rinda katrai tabulas rindai. Protams, to pašu var teikt par klasterizētu indeksu, pieņemot, ka šāds indekss ir tabula. Bet, kad runa ir par indeksu, kas nav grupēts, attiecības viens pret vienu ir svarīgs jēdziens, jo, sākot ar versiju SQL Server 2008, jums ir iespēja izveidot filtrējamu indeksu, kas ierobežo tajā iekļautās rindas. Filtrēts indekss var uzlabot vaicājuma veiktspēju, jo... tā ir mazāka izmēra un satur filtrētu, precīzāku statistiku nekā visas tabulas - tādējādi tiek izveidoti uzlaboti izpildes plāni. Filtrētam indeksam ir nepieciešams arī mazāk vietas uzglabāšanai un zemākas uzturēšanas izmaksas. Indekss tiek atjaunināts tikai tad, kad mainās dati, kas atbilst filtram.
Turklāt ir viegli izveidot filtrējamu indeksu. Operatorā IZVEIDOT INDEKSU jums tikai jānorāda KUR filtra stāvoklis. Piemēram, varat filtrēt no indeksa visas rindas, kurās ir NULL, kā parādīts kodā:
CREATE NONCLUSTERED INDEX ix_trackingnumber ON Sales.SalesOrderDetail(CarrierTrackingNumber) KUR CarrierTrackingNumber NAV NULL;
Mēs faktiski varam filtrēt visus datus, kas nav svarīgi kritiskos vaicājumos. Bet esiet uzmanīgi, jo... SQL serveris uzliek vairākus ierobežojumus filtrējamiem indeksiem, piemēram, nespēja izveidot skatā filtrējamu indeksu, tāpēc uzmanīgi izlasiet dokumentāciju.
Var arī būt, ka līdzīgus rezultātus varat sasniegt, izveidojot indeksētu skatu. Tomēr filtrētam indeksam ir vairākas priekšrocības, piemēram, iespēja samazināt uzturēšanas izmaksas un uzlabot izpildes plānu kvalitāti. Filtrētos indeksus var arī atjaunot tiešsaistē. Izmēģiniet to ar indeksētu skatu.

Un atkal mazliet no tulka

Izskata mērķis šī tulkojuma Habrahabr lapās tas bija paredzēts, lai pastāstītu vai atgādinātu par SimpleTalk emuāru no RedGate.
Tajā tiek publicētas daudzas izklaidējošas un interesantas ziņas.
Es neesmu saistīts ar neviena uzņēmuma produktiem RedGate, ne ar to pārdošanu.

Kā solīts, grāmatas tiem, kas vēlas uzzināt vairāk
Es iesaku trīs ļoti labas grāmatas no sevis (saites ved uz iekurt versijas veikalā Amazon):

Principā jūs varat atvērt vienkāršus indeksus Pievienot tagus

Microsoft SQL Server 2012 T-SQL pamati (izstrādātāja atsauce) Autors Itzik Ben-Gan Publicēšanas datums: 2012. gada 15. jūlijs Autors, sava amata meistars, dod pamatzināšanas par darbu ar datu bāzēm. Ja esi visu aizmirsis vai nekad nezinājis, noteikti ir vērts izlasīt.

ROWID indeksi ir datu bāzes objekti, kas nodrošina visu vērtību attēlojumu tabulas kolonnā, kā arī visu tabulas rindu ROWID, kas satur kolonnas vērtības.

ROWID ir pseido kolonna, kas ir unikāls tabulas rindas identifikators un faktiski apraksta šīs konkrētās rindas precīzu fizisko atrašanās vietu. Pamatojoties uz šo informāciju Orākuls pēc tam var atrast datus, kas saistīti ar tabulas rindu. Katru reizi, kad rinda tiek pārvietota, eksportēta, importēta vai tiek veikta cita darbība, kas maina tās atrašanās vietu, ROWID līniju, jo tā ieņem atšķirīgu fizisko stāvokli. Datu glabāšanai ROWID Nepieciešami 80 biti (10 baiti). Identifikatori ROWID sastāv no četrām sastāvdaļām: objekta numura (32 biti), relatīvā faila numura (10 biti), bloka numura (22 biti) un rindas numura (16 biti). Šie identifikatori tiek parādīti kā 18 rakstzīmju sekvences, kas norāda datu atrašanās vietu datu bāzē, katra rakstzīme ir attēlota bāzes-64 formātā, kas sastāv no rakstzīmes A-Z, a-z, 0-9, + un /. Pirmās sešas rakstzīmes ir datu objekta numurs, nākamās trīs ir relatīvais faila numurs, nākamās sešas ir bloka numurs un pēdējās trīs ir rindas numurs.

Piemērs:

IZVĒLIES ģimeni, ROWID NO studenta;

FAM ROWID

——————————————

IVANOVS AAAA3kAAGAAAAGsAAA

PETROVS AAAA3kAAGAAAAGsAAB

Datu bāzē Orākuls indeksi tiek izmantoti dažādiem mērķiem: lai nodrošinātu vērtību unikalitāti datu bāzē, lai uzlabotu ierakstu meklēšanas veiktspēju tabulā utt. Veiktspēja tiek uzlabota, meklēšanas kritērijos iekļaujot atsauci uz indeksēto kolonnu vai kolonnām datiem tabulā. IN Orākuls indeksus var izveidot jebkurā tabulas kolonnā, izņemot LONG kolonnas. Indeksi atšķir lietojumprogrammas, kas nav jutīgas pret ātrumu, un augstas veiktspējas lietojumprogrammas, īpaši, strādājot ar lielām tabulām. Tomēr, pirms izlemjat izveidot indeksu, jums ir jāizvērtē sistēmas veiktspējas plusi un mīnusi. Veiktspēja neuzlabosies, ja vienkārši ievadīsit indeksu un aizmirsīsit par to.

Lai gan lielākais veiktspējas uzlabojums rodas, izveidojot indeksu kolonnā, kurā visas vērtības ir unikālas, līdzīgus rezultātus varat iegūt kolonnām, kurās ir dublētas vai NULL vērtības. Lai izveidotu indeksu, kolonnu vērtībām nav jābūt unikālām. Šeit ir daži ieteikumi, kas palīdzēs sasniegt vēlamo veiktspējas palielinājumu, izmantojot standarta indeksu, un mēs arī apskatīsim problēmas, kas saistītas ar veiktspējas un diska vietas patēriņa līdzsvaru, veidojot indeksu.

Izmantojot indeksus, lai meklētu informāciju tabulās, var nodrošināt ievērojamus veiktspējas uzlabojumus salīdzinājumā ar skenēšanas tabulām, kuru kolonnas nav indeksētas. Tomēr izvēlēties pareizo indeksu nepavisam nav viegli. Protams, kolonna, kuras vērtības visas ir unikālas, ir ieteicama indeksēšanai ar B-koka indeksu, taču kolonna, kas neatbilst šīm prasībām, ir laba kandidāte, ja vien aptuveni 10% no tās rindām satur identiskas vērtības. un ne vairāk. Slejas “Switch” vai “flag”, piemēram, tās, kurās tiek glabāta informācija par personas dzimumu, nav piemērotas B-koka indeksiem. Slejas, kas tiek izmantotas, lai saglabātu nelielu skaitu “uzticamu vērtību”, kā arī tās, kurās tiek saglabāta informācija. noteiktas vērtības arī nav piemērotas, tad zīmes, piemēram, "uzticamība" vai "neuzticamība", "aktivitāte" vai "neaktivitāte", "jā" vai "nē" utt., utt. Visbeidzot, indeksi ar apgrieztiem taustiņiem ir parasti izmanto, kur tas ir uzstādīts un darbojas Orākuls Parallel Server un jums ir jāpalielina paralēlisma līmenis datu bāzē līdz maksimālajam līmenim.

Sākumā es iesaku jums izdomāt, kas tas ir aptverošais indekss, es sniegšu fragmentu no raksta par Habrē:

Kāpēc izmantot aptverošu indeksu, nevis saliktu indeksu?
Pirmkārt, pārliecināsimies, ka mēs saprotam atšķirību starp abiem.
Salikts indekss tas ir tikai parasts rādītājs, kas ietver vairāk nekā vienu kolonnu. Var izmantot vairākas atslēgu kolonnas, lai nodrošinātu, ka katra tabulas rinda ir unikāla, vai arī jums var būt vairākas kolonnas, lai nodrošinātu, ka primārā atslēga ir unikāla, vai arī jūs mēģināt optimizēt bieži izsaukto vaicājumu izpildi vairākās kolonnās. Tomēr kopumā, jo vairāk galveno sleju indekss satur, jo mazāk efektīvs būs indekss, kas nozīmē, ka saliktie indeksi ir jāizmanto saprātīgi.

Kā minēts, vaicājums var gūt lielu labumu, ja visi nepieciešamie dati uzreiz atrodas indeksa lapās, tāpat kā pats rādītājs. Klasterizētam indeksam tā nav problēma, jo visi dati jau ir tur (tāpēc ir tik svarīgi rūpīgi pārdomāt, veidojot kopu indeksu). Bet lapu indeksā, kas nav grupēts, ir tikai galvenās kolonnas. Lai piekļūtu visiem pārējiem datiem, vaicājumu optimizētājam ir jāveic papildu darbības, kas var ievērojami palielināt vaicājumu izpildi.

Tieši tur aptverošais indekss steidzas palīgā. Kad definējat negrupētu indeksu, galvenajām kolonnām varat norādīt papildu kolonnas.

Tādējādi aptverošajā indeksā nedrīkst būt visas vaicājuma atlasāmās kolonnas indeksa koka struktūrā, bet tikai tās, kuras tiks izmantotas vaicājuma datu filtrēšanai vai grupēšanai, pārējās kolonnas no sadaļas SELECT jāievieto IEKĻAUJ indeksa sadaļu.

Atbilde uz citu jautājumu varētu būt noderīga.

Iepriekš minētajā piemērā tiek izmantots 3 lauku salikts indekss, nevis aptverošais indekss; aptverošā indeksa izveides kods izskatītos šādi:

IZVEIDOT NEKLUSTERĒTU INDEKSU . ( ASC) IEKĻAUJIET (, ) AR (PAD_INDEX = IZSLĒGTS, STATISTICS_NORECOMPUTE = IZSLĒGTS, SORT_IN_TEMPDB = IZSLĒGTS, IGNORE_DUP_KEY = IZSLĒGTS, DROP_EXISTING = IZSLĒGTS, ONLINE = IZSLĒGTS, ALLOW_ROW_LOCKSON_ONAGE)

Lai atbildētu uz jūsu jautājumu:

aptverošajam indeksam kolonnu secība sadaļā IEKĻAUTI nav svarīgi, bet kolonnu secība ir svarīga saliktam indeksam, jo Kolonnu dati tiek ievietoti indeksu kokā kolonnu sarakstā norādītajā secībā, un vaicājumu optimizētājs nevarēs izmantot 2 kolonnu indeksu, lai meklētu tikai 2 kolonnu vērtības. Attēlā var redzēt skaidru piemēru, kā izskatīsies 2 kolonnu indeksa struktūra (EMPLOYEE_ID, SUBSIDIARY_ID).

1) Indeksa jēdziens
Rādītājs ir rīks, kas nodrošina ātru piekļuvi tabulas rindām, pamatojoties uz vienas vai vairāku kolonnu vērtībām.

Šim operatoram ir daudz dažādu veidu, jo tas nav standartizēts, jo standarti nerisina veiktspējas problēmas.

2) Indeksu veidošana
IZVEIDOT INDEKSU
IESLĒGTS()

3) indeksu maiņa un dzēšana
Lai kontrolētu indeksa darbību, tiek izmantots operators:
MAINĪT INDEKSU
Lai noņemtu indeksu, izmantojiet operatoru:
NOTEIKT INDEKSU

a) Tabulu atlases noteikumi
1. Vēlams indeksēt tabulas, kurās atlasīti ne vairāk kā 5% rindu.
2. Tabulas, kurām SELECT priekšraksta WHERE klauzulā nav dublikātu, ir jāindeksē.
3. Nav praktiski indeksēt bieži atjauninātas tabulas.
4. Nav pareizi indeksēt tabulas, kas aizņem ne vairāk kā 2 lappuses (Oracle tas ir mazāks par 300 rindām), jo tās pilna skenēšana neaizņem ilgāku laiku.

b) Kolonnu atlases noteikumi
1. Primārās un ārējās atslēgas — bieži izmanto, lai savienotu tabulas, izgūtu datus un meklētu. Tie vienmēr ir unikāli indeksi ar maksimālu lietderību
2. Izmantojot atsauces integritātes opcijas, vienmēr ir nepieciešams rādītājs FK.
3. Kolonnas, pēc kurām dati bieži tiek kārtoti un/vai grupēti.
4. Slejas, kuras bieži tiek meklētas SELECT priekšraksta WHERE klauzulā.
5. Nevajadzētu veidot indeksus garās aprakstošās kolonnās.

c) Saliktu indeksu izveides principi
1. Saliktie indeksi ir labi, ja atsevišķām kolonnām ir maz unikālu vērtību, bet salikts indekss nodrošina lielāku unikalitāti.
2. Ja visas ar SELECT priekšrakstu atlasītās vērtības pieder saliktam indeksam, tad vērtības tiek atlasītas no indeksa.
3. Salikts indekss ir jāizveido, ja WHERE klauzula izmanto divas vai vairākas vērtības, kas apvienotas ar operatoru UN.

d) Nav ieteicams izveidot
Nav ieteicams veidot indeksus kolonnām, tostarp saliktajām, kas:
1. Reti tiek izmantots vaicājumu rezultātu meklēšanai, apvienošanai un kārtošanai.
2. Satur bieži mainīgas vērtības, kas prasa bieži atjauninājumi indekss palēnina datu bāzes veiktspēju.
3. Satur nelielu skaitu unikālu vērtību (mazāk nekā 10% m/f) vai dominējošu līniju skaitu ar vienu vai divām vērtībām (piegādātāja dzīvesvieta ir Maskava).
4. Klauzulā WHERE tām tiek piemērotas funkcijas vai izteiksme, un indekss nedarbojas.

e) Mēs nedrīkstam aizmirst
Jums jācenšas samazināt indeksu skaitu, jo liels indeksu skaits samazina datu atjaunināšanas ātrumu. Tādējādi MS SQL Server iesaka izveidot ne vairāk kā 16 indeksus katrā tabulā.
Parasti indeksi tiek izveidoti vaicājumu nolūkos un atsauces integritātes uzturēšanai.
Ja indekss netiek izmantots vaicājumiem, tas ir jāizdzēš un, izmantojot trigerus, jānodrošina atsauces integritāte.