det här är den fjärde artikeln i en serie att lära sig Skapa vy SQL-satsen. Hittills har vi gjort en hel del att skapa och ändra vyer med T-SQL. I denna sista del vill jag ta en stor titt på hur man arbetar med indexerade vyer.

som alltid, för att följa med serien, rekommenderas det starkt att läsa de tidigare delarna först och sedan den här., Detta beror främst på att vi skapade vår egen provdatabas och objekt i det från början som vi kommer att använda i den här delen också, men också för att det blir mycket lättare att se helheten.

här är de tidigare tre delarna av CREATE VIEW SQL-serien:

• skapa vyer i SQL Server
• ändra vyer i SQL Server
• infoga data genom vyer i SQL Server

så, gå över och läs dem innan du fortsätter med den här.

introduktion

det första vi ska göra är att skapa en indexerad vy., Vi kommer naturligtvis att använda CREATE VIEW SQL-satsen för detta som vi gjorde många gånger genom serien. Men den allmänna idén, som titeln säger, är att se hur man arbetar med indexerade vyer, se vad kraven är för att lägga till ett index i en vy och hur man gör det programmatiskt. Dessutom, för att förklara proffsen av indexerade vyer, vi kommer att titta på avrättningar planer i SQL Server. De är ett bra verktyg för DBAs och utvecklare när det gäller att hitta och fixa en flaskhals i den långsamma frågan.,

utan ytterligare ado, låt oss skapa en vy med hjälp av CREATE VIEW SQL-satsen underifrån och se vad den gör:

Observera att den här vyn har ett SCHEMABINDANDE alternativ på den. Anledningen till att det har det här alternativet aktiverat är att när du skapar index på vyer, blir de faktiskt fysiskt lagrade i databasen. Med andra ord, allt som denna uppfattning bygger på, när det gäller tabellerna, kan strukturen inte förändras från vad vi refererar till.

därför måste den vara bunden till de underliggande tabellerna så att vi inte kan ändra dem på ett sätt som skulle påverka visningsdefinitionen., Om vi försöker ändra dem på något sätt kommer SQL Server att kasta ett fel som säger att den här vyn beror på något. Så, titta på det som ett svårt krav för att skapa ett index på en vy.

när kommandot har utförts, bör du se vemployeesalesorders-vyn under visningsmappen i Object Explorer som visas nedan:

definitionen av vyn är lite mer komplex fråga. Vi fick ett aggregat i SELECT-uttalandet följt av GROUP BY-klausulen., Kom ihåg att när vi har ett aggregat i frågan lägger det ihop siffrorna, så vi måste ha gruppen för klausul.

i grund och botten, när det finns en grupp av i en fråga, måste vi gruppera efter allt som finns i select-listan utom aggregatet.,

nu har jag redan skapat vyn, men kom ihåg att det alltid är en bra idé att testa definitionen av vyn genom att bara köra den valda delen av create VIEW SQL-satsen för att se vad den returnerar:

gå vidare, Så här kan du kontrollera om alternativet Schemabunden är aktiverat eller inaktiverat., Gå över till Object Explorer, expandera vyer, högerklicka på vyn och välj Egenskaper:

bland all annan information i fönstret Visa egenskaper ser du om alternativet Schemabunden är inställt på Sant eller falskt under den allmänna sidan.

skapa indexerade vyer

låt oss gå vidare och skapa ett index på vår vy., Consider the script from below for creating a clustered index on the vEmployeeSalesOrders view:

om vi trycker på Execute-knappen i SSMS kommer SQL Server att kasta ett fel som säger att indexet inte kan skapas:

här är det fullständiga felmeddelandet som inte kan ses i skottet ovan:

kan inte skapa index på View ’sqlshackdb.dbo.vEmployeeSalesOrders ’ eftersom dess Välj lista inte innehåller en korrekt användning av COUNT_BIG. Överväg att lägga till COUNT_BIG ( * ) för att välja lista.,

vi behöver COUNT_BIG i det här fallet med tanke på att vi använder GROUP BY enligt vår uppfattning.

i allmänhet, om vi använder aggregat som COUNT, SUM, AVG, etc. i indexets Välj lista måste vi också inkludera COUNT_BIG för att skapa ett index på det.

det är precis vad vi ska göra.,använda create VIEW SQL-satsen och Lägg till COUNT_BIG i listan select med hjälp av skriptet underifrån:

om du undrar varför detta händer i det här fallet beror svaret på att SQL Server behöver ett sätt att spåra numret på posten som vi vrider för indexet och det här är också en av en hel massa begränsningar med att skapa indexerade vyer.

hittills ser allt bra ut. Vi har ändrat definitionen av vår vy:

Nu kan vi komma tillbaka till att skapa ett index på vyn genom att köra det tidigare använda skriptet en gång till., Den här gången kommer operationen att slutföra smidigt. Om vi går till Object Explorer och expanderar Indexmappen i vår vy ser vi det nyskapade indexet:

härifrån, om vi högerklickar på indexet och väljer Egenskaper, under den allmänna sidan kan du se visningsnamn, indexnamn, typ, nyckelkolumner etc.,

om vi byter till lagring ser du att den har en filgrupp eftersom den är fysiskt lagrad i en databas:

vidare, om vi byter till fragmentering, bör det stå att total fragmentering är noll procent eftersom vi bara har några poster i våra tabeller:

Letar efter en detaljerad men rolig och lättläst primer på underhåll och övervakning SQL index? Kolla in SQL index underhåll.,

radera index

innan vi går vidare, Låt oss se hur vi kan ta bort ett index. Det enklaste sättet är att högerklicka på indexet i Object Explorer och använda alternativet Ta bort. Men om du behöver släppa flera index på en gång, kommer DROP INDEX uttalande praktiskt. Det är vad vi ska göra, för det här är trots allt en T-SQL-serie om att lära sig create VIEW SQL-satsen.,

Use the script from below to drop the CAK_vEmployeesSalesOrders index:

När du behöver släppa flera index anger du bara alla namn åtskilda av ett kommatecken.

generera slumpmässiga data

nu, att vi blev av med indexet, låt oss generera några slumpmässiga data i vår tabell så att vi kan titta på exekveringsplanen och se hur SQL Server hämtar data under huven. Att analysera exekveringsplanen visar skillnaden i hur resultatet påverkas genom att köra frågan med och utan ett index i vyn.,

använd skriptet underifrån för att infoga 50000 slumpmässiga poster i Försäljningstabellen:

Jag kommer inte att gå igenom skriptet i detaljer, men det är i grunden en slinga som kommer att utföra 50000 gånger och Infoga slumpmässiga data i försäljningstabellen., för att kontrollera om posterna har infogats, utför följande SELECT-sats som räknar alla poster från försäljningstabellen:

numret som returneras visar att det finns 50006 rader i försäljningstabellen., Det här är antalet poster som vi just genererade + 6 som vi ursprungligen hade:

analysera exekveringsplaner

Nu när vi har några data i vårt bord kan vi verkligen visa användningen av ett index på vyn. Låt oss fråga vEmployeeSalesOrders visa och se hur SQL Server hämtar data., Before executing the SELECT statement from below, make sure to include the Actual Execution Plan as shown below:

det här skriptet returnerade 23814 rader, men vad som är viktigare genererade det exekveringsplanen för frågan. Kom ihåg att vi tidigare tappade indexet på vår uppfattning. Så just nu finns det inget index på vår uppfattning. Därför kommer SQL Server att göra några tabellskanningar som visas nedan:

det här är ganska mycket det värsta i databasvärlden, särskilt på tabeller med en stor mängd data., Det är okej att ha tabellskanningar med en liten mängd data, t.ex. fallet med våra anställda och Produkttabeller, men det är dåligt för Försäljningstabellen eftersom det har 50K+ – poster.

det enklaste sättet att bli av med tabellskanningarna är att skapa ett index på det eftersom det dramatiskt påskyndar saker och ting. Så, vad vi ska göra för att åtgärda detta problem är att åter köra skriptet för att skapa det unika klustrade indexet på vEmployeeSalesOrders-vyn.

Nu, om vi bara kör SELECT-satsen igen, kommer det inte att finnas några skillnader även om vi bara skapade indexet. Varför det?, Eftersom jag använder SQL Server Express edition i syfte att denna serie, och endast i Enterprise och Developer utgåvor av SQL Server kommer Query Optimizer faktiskt ta indexet i beaktande.

inga bekymmer eftersom vi faktiskt kan tvinga SQL Server att använda ett index vid generering av exekveringsplaner. Detta görs genom att använda alternativet NOEXPAND., NOEXPAND gäller endast för indexerade vyer:

precis som det tvingade vi SQL Server att använda det grupperade indexet vilket i princip innebär att vi inte använder de underliggande tabellerna när vi hämtar data., Som framgår nedan har vi gjort vissa framsteg genom att eliminera ett antal operationer:

i själva verket kan vi exekverabåde välja uttalanden samtidigt och jämföra resultaten genom att titta på exekveringsplanerna:

skulle du titta på det? Om vi jämför frågekostnaden för den första select-satsen (w / o index 95%) till den andra SELECT-satsen (w/ index 5%), skulle jag säga att det är en stor prestationsvinst med ett enda index.,

slutsats

index är bra eftersom de påskyndar prestanda och med ett index på en vy bör det verkligen påskynda prestanda eftersom indexet lagras i databasen. Indexering både visningar och tabeller är ett av de mest effektiva sätten att förbättra prestanda för frågor och program som använder dem.

Jag vill avsluta den här serien med att lära sig skapa vyn SQL-satsen med den här artikeln. Vi har ganska mycket täckt allt om att skapa och ändra vyer med T-SQL., Vi började med CREATE VIEW SQL-satsen, skapade några vyer, ändrade dem, raderade och mycket mer.

Jag hoppas att den här serien att lära sig skapa vyn SQL-satsen har varit informativ för dig och jag tackar dig för att du läste den.,

skapa visa SQL: infoga data genom vyer i SQL Server

skapa visa SQL: arbeta med indexerade vyer i SQL Server

• författare
• Senaste inlägg

Bojan aka ”boksi”, en AP-examen i IT-teknik med fokus på Nätverk och elektronisk teknik från Köpenhamns skola för design och teknik, är en mjukvaruanalytiker med erfarenhet av kvalitetssäkring, programvarusupport, produkt evangelism och användarengagemang.,
han har skrivit mycket om både SQL Shack och ApexSQL Solution Center, om ämnen som sträcker sig från klientteknik som 4K-upplösning och teman, felhantering till indexstrategier och prestandaövervakning.
Bojan fungerar på ApexSQL i Nis, Serbien som en integrerad del av det team som fokuserar på att designa, utveckla och testa nästa generation av databas verktyg, bland annat MySQL och SQL Server, och både fristående verktyg och integration i Visual Studio, SSMS, och VSCode.,
se mer om Bojan på LinkedIn
Visa alla inlägg av Bojan Petrovic

Senaste inlägg av Bojan Petrovic (se alla)

• Visual Studio Code for MySQL and MariaDB development – 13 augusti 2020
• SQL UPDATE syntax explained – 10 juli 2020
• Skapa vy SQL: arbeta med indexerade vyer i SQL Server – Mars 24, 2020