1. For at optimere forespørgslen bør du forsøge at undgå fuld tabelscanning og først overveje at oprette et indeks over de anvendte kolonner i 'where' og ordne efter.
2. Prøv at undgå nullværdidom på felter i where-klausulen, ellers vil det få motoren til at opgive brugen af indekser og udføre fuld tabelscanning, såsom:
Vælg id fra t hvor num er null
Du kan sætte standardværdien 0 på num, sikre dig, at der ikke er nulværdi i num-kolonnen i tabellen, og så forespørge sådan her:
Vælg id fra t hvor num=0
3. Prøv at undgå at bruge != eller <> operatorer i where-klausulen, ellers opgiver motoren brugen af indekser og udfører fuldtabel-scanning.
4. Du bør forsøge at undgå at bruge OR i where-klausulen for at slutte dig til betingelsen, ellers vil det få motoren til at opgive brugen af indekser og udføre en fuld tabelscanning, såsom:
Vælg ID fra T, hvor num=10 eller num=20
Du kan forestille sådan her:
Vælg id fra t hvor num=10
Forening alle
Vælg id fra t hvor num=20
5.in og ikke i bør også bruges med forsigtighed, ellers vil det føre til fuld bordscanning, såsom:
Vælg ID fra t hvor num in(1,2,3)
For kontinuerte værdier skal du ikke bruge i, hvis du kan bruge mellem:
Vælg ID fra T, hvor Num er mellem 1 og 3
6. Følgende forespørgsel vil også resultere i en fuld tabelscanning:
Vælg ID fra T, hvor navn som '%abc%'
For at forbedre effektiviteten kan du overveje fuldtekstsøgning.
7. Hvis du bruger en parameter i en where-klausul, vil det også forårsage en fuld tabelscanning. Fordi SQL kun løser lokale variabler under kørsel, men optimereren ikke kan udsætte valget af adgangsplaner til kørsel; Den skal vælges ved kompilering. Hvis der dog oprettes en adgangsplan ved kompilering, er værdien af variablen stadig ukendt og kan derfor ikke bruges som inputelement til indeksvalg. Følgende udsagn vil blive scannet i sin helhed:
Vælg id fra t hvor num=@num
Du kan tvinge forespørgslen til at bruge et indeks i stedet:
Vælg ID fra t med(indeks(indeks(indeksnavn)) hvor num=@num
8. Prøv at undgå at udtrykke felter i where-klausulen, da det vil få motoren til at opgive brugen af indekser til fordel for fuld tabelscanning. For eksempel:
Vælg ID fra t hvor num/2=100
bør ændres til:
Vælg id fra t hvor num=100*2
9. Prøv at undgå at udføre funktionsoperationer på felter i where-klausulen, hvilket vil få motoren til at opgive brugen af indekser til fordel for fuld tabelscanning. For eksempel:
Vælg id fra t hvor substring(name,1,3)='abc' --navn-id der starter med abc
Vælg ID fra t hvor datediff(day,createdate,'2005-11-30')=0--'2005-11-30' genererede id
bør ændres til:
Vælg ID fra T, hvor navn som 'ABC%'
Vælg ID fra T hvor CreateDate>='2005-11-30' og CreateDate<'2005-12-1'
10. Udfør ikke funktioner, aritmetiske operationer eller andre udtryksoperationer til venstre for "=" i where-klausulen, ellers kan systemet muligvis ikke bruge indekset korrekt.
11. Når man bruger et indeksfelt som betingelse, hvis indekset er et sammensat indeks, skal det første felt i indekset bruges som betingelse for at sikre, at systemet bruger indekset, ellers vil indekset ikke blive brugt, og rækkefølgen af felterne bør være så konsistent som muligt med indeksrækkefølgen.
12. Skriv ikke meningsløse forespørgsler, såsom at generere en tom tabelstruktur:
Vælg kol1,kol2 ind i #t fra t hvor 1=0
Denne type kode returnerer ikke noget resultatsæt, men den bruger systemressourcer, så den bør ændres til noget i retning af dette:
Opret tabel #t(...)
13. Ofte er det et godt valg at erstatte med eksisterende steder:
Vælg num fra a, hvor num er ind (vælg num fra b)
Erstat med følgende udsagn:
Vælg Num fra A, hvor der findes (vælg 1 fra B, hvor num=A.Num)
14. Ikke alle indekser er gyldige for forespørgsler, SQL er baseret på dataene i tabellen for at optimere forespørgslen, når indekskolonnen har en stor mængde dataduplikation, kan SQL-forespørgsler ikke bruge indekset, for eksempel at en tabel har et felt, køn, mand, kvinde er næsten halvdelen hver, så selv hvis indekset er bygget på køn, vil det ikke spille nogen rolle i forespørgselseffektiviteten.
15. Jo flere indeks ikke er, desto bedre, indekset kan bestemt forbedre effektiviteten af den tilsvarende select, men det reducerer også effektiviteten af indsættelse og opdatering, fordi indekset kan genopbygges ved indsættelse eller opdatering, så hvordan man bygger et indeks skal overvejes nøje afhængigt af den specifikke situation. Det er bedst ikke at have mere end 6 indekser i en tabel, og hvis der er for mange, bør man overveje, om det er nødvendigt at bygge indekser på nogle sjældent brugte kolonner.
16. Undgå at opdatere kolonner med klyngeindeksdata så meget som muligt, da rækkefølgen af kolonner med klyngede indeksdata er den fysiske lagerrækkefølge for tabellens poster, og når kolonneværdien ændres, vil det føre til justering af rækkefølgen af hele tabellen, hvilket vil forbruge betydelige ressourcer. Hvis din applikation ofte skal opdatere klyngede indekskolonner, skal du overveje, om du skal bygge indekset som et klyngeindeks.
17. Prøv at bruge numeriske felter, og prøv ikke at designe felter, der kun indeholder numerisk information som tegn, da det vil reducere ydeevnen af forespørgsler og forbindelser og øge lageroverhead. Dette skyldes, at motoren sammenligner hvert tegn i strengen én for én, når forespørgsler og joins behandles, mens den for numeriske typer kun behøver at blive sammenlignet én gang.
18. Brug varchar/nvarchar i stedet for char/nchar så meget som muligt, fordi for det første kan det længere feltlagringsplads spare lagerplads, og for det andet er søgeeffektiviteten i et relativt lille felt åbenlyst højere for forespørgsler.
19. Brug ikke vælg * fra t nogen steder, erstat "*" med en specifik liste af felter, og returner ikke felter, der ikke er brugt.
20. Prøv at bruge tabelvariabler i stedet for midlertidige tabeller. Hvis tabelvariablen indeholder en stor mængde data, skal man bemærke, at indekset er meget begrænset (kun primærnøgleindekset).
21. Undgå hyppig oprettelse og sletning af midlertidige tabeller for at reducere forbruget af systemtabelressourcer.
22. Midlertidige tabeller er ikke ubrugelige, og korrekt brug kan gøre nogle rutiner mere effektive, for eksempel når man gentagne gange skal referere til et datasæt i en stor eller almindeligt brugt tabel. Men til engangsbegivenheder er det bedst at bruge en eksporttabel.
23. Når du opretter en midlertidig tabel, hvis mængden af data indsat på én gang er stor, kan du bruge select i i stedet for at oprette tabel for at undgå at forårsage et stort antal logs for at forbedre hastigheden; Hvis datamængden ikke er stor, bør du for at lette ressourcerne i systemtabellen først oprette tabellen og derefter indsætte den.
24. Hvis en midlertidig tabel bruges, skal du sørge for eksplicit at slette alle midlertidige tabeller i slutningen af den lagrede procedure, afkorte tabellen først, og derefter fjerne tabellen, så systemtabellen ikke bliver låst i lang tid.
25. Prøv at undgå at bruge markøren, fordi markørens effektivitet er dårlig; hvis dataene, som markøren behandler, overstiger 10.000 linjer, bør du overveje at omskrive.
26. Mængdebaserede løsninger bør søges for at løse problemer, før man bruger cursorbaserede eller midlertidige tabelmetoder, som ofte er mere effektive.
27. Ligesom midlertidige tabeller er cursors ikke ubrugelige. At bruge FAST_FORWARD cursors til små datasæt er ofte bedre end andre række-for-række-behandlingsmetoder, især hvis du skal referere til flere tabeller for at få de data, du har brug for. Rutiner, der inkluderer "total" i resultatsættet, er som regel hurtigere end dem, der udføres med markøren. Hvis udviklingstiden tillader det, kan både cursorbaserede og mængdebaserede metoder prøves for at se, hvilken der fungerer bedst.
28. Sæt SET NOCOUNT ON i starten af alle lagrede procedurer og triggere, og SET NOCOUNT OFF til sidst. Der er ikke behov for at sende DONE_IN_PROC beskeder til klienten efter at have udført hver sætning i den lagrede procedure og trigger.
29. Forsøg at undgå store transaktionsoperationer og forbedre systemets samtidighedskapacitet.
30. Prøv at undgå at returnere store data til klienten; hvis datamængden er for stor, bør du overveje, om den tilsvarende efterspørgsel er rimelig. |
Opslået på 27/01/2015 20.09.54
|
|
|
