1. For å optimalisere spørringen bør du prøve å unngå full tabellskanning, og først vurdere å lage en indeks over kolonnene involvert i hvor og sorter etter.
2. Prøv å unngå nullverdivurdering på felt i where-klausulen, ellers vil det føre til at motoren slutter å bruke indekser og utfører full tabellskanning, for eksempel:
Velg id fra t hvor num er null
Du kan sette standardverdien 0 på num, sørge for at det ikke finnes nullverdi i num-kolonnen i tabellen, og så spørre slik:
velg id fra t hvor num=0
3. Prøv å unngå å bruke != eller <> operatorer i where-klausulen, ellers vil motoren slutte å bruke indekser og utføre fullbordsskanning.
4. Du bør prøve å unngå å bruke OR i where-klausulen for å bli med i betingelsen, ellers vil det føre til at motoren slutter å bruke indekser og utfører en full tabellskanning, for eksempel:
Velg ID fra t hvor num=10 eller num=20
Du kan spørre slik:
Velg ID fra t hvor num=10
Forening alle
Velg ID fra t hvor num=20
5.in og ikke i bør også brukes med forsiktighet, ellers vil det føre til full bordskanning, for eksempel:
Velg ID fra t hvor num in(1,2,3)
For kontinuerlige verdier, ikke bruk i hvis du kan bruke mellom:
Velg ID fra T der Num er mellom 1 og 3
6. Følgende spørring vil også resultere i en fullstendig tabellskanning:
Velg ID fra t hvor navn som '%abc%'
For å øke effektiviteten, vurder fulltekstsøk.
7. Hvis du bruker en parameter i en where-klausul, vil det også føre til en full tabellskanning. Fordi SQL kun løser lokale variabler under kjøring, men optimalisatoren kan ikke utsette valget av tilgangsplaner til kjøretid; Den må velges ved kompilering. Men hvis en tilgangsplan etableres ved kompilering, er verdien til variabelen fortsatt ukjent og kan derfor ikke brukes som et inngangselement for indeksvalg. Følgende erklæringer vil bli skannet i sin helhet:
Velg ID fra t der num=@num
Du kan tvinge spørringen til å bruke en indeks i stedet:
Velg ID fra t med(indeks(indeks(indeksnavn)) hvor num=@num
8. Prøv å unngå å uttrykke felt i where-klausulen, noe som vil føre til at motoren slutter å bruke indekser til fordel for full tabellskanning. For eksempel:
Velg ID fra t der num/2=100
bør endres til:
Velg ID fra T hvor num=100*2
9. Prøv å unngå å utføre funksjonsoperasjoner på felt i where-klausulen, noe som vil føre til at motoren gir opp bruken av indekser til fordel for full tabellskanning. For eksempel:
Velg ID fra t hvor substring(name,1,3)='abc' --navn-id som starter med abc
Velg ID fra t hvor datediff(day,createdate,'2005-11-30')=0--'2005-11-30' genererte id
bør endres til:
Velg ID fra t hvor navn som 'abc%'
Velg ID fra T hvor CreateDate>='2005-11-30' og CreateDate<'2005-12-1'
10. Ikke utfør funksjoner, aritmetiske operasjoner eller andre uttrykksoperasjoner til venstre for "=" i where-klausulen, ellers kan systemet kanskje ikke bruke indeksen korrekt.
11. Når man bruker et indeksfelt som betingelse, hvis indeksen er en sammensatt indeks, må det første feltet i indeksen brukes som betingelse for å sikre at systemet bruker indeksen, ellers vil ikke indeksen bli brukt, og rekkefølgen på feltene bør være i samsvar med indeksrekkefølgen så mye som mulig.
12. Ikke skriv meningsløse spørringer, som å generere en tom tabellstruktur:
Velg kol1,kol2 inn i #t fra t hvor 1=0
Denne typen kode returnerer ikke noe resultatsett, men den bruker systemressurser, så den bør endres til noe slik:
Opprett tabell #t(...)
13. Ofte er det et godt valg å erstatte med at det finnes:
Velg num fra a hvor num inn (velg num fra b)
Erstatt ut med følgende utsagn:
Velg Num fra A hvor finnes (velg 1 fra B hvor Num=A.Num)
14. Ikke alle indekser er gyldige for spørringer, SQL er basert på dataene i tabellen for å optimalisere spørringen, når indekskolonnen har mye dataduplisering, kan SQL-spørringer ikke bruke indeksen, for eksempel at en tabell har et felt, kjønn, mann, kvinne er nesten halvparten hver, og selv om indeksen er bygget på kjønn, vil det ikke spille noen rolle i spørringseffektiviteten.
15. Jo flere indekser ikke er bedre, desto bedre kan indeksen absolutt forbedre effektiviteten til den tilsvarende selecten, men den reduserer også effektiviteten ved innsetting og oppdatering, fordi indeksen kan bygges opp igjen ved innsetting eller oppdatering, så hvordan man bygger en indeks må vurderes nøye, avhengig av den spesifikke situasjonen. Det er best å ikke ha mer enn 6 indekser i en tabell, og hvis det er for mange, vurder om det er nødvendig å bygge indekser på noen sjeldent brukte kolonner.
16. Unngå å oppdatere kolonner for klyngede indeksdata så mye som mulig, fordi rekkefølgen på klyngede indeksdatakolonner er den fysiske lagringsrekkefølgen for tabellposter, og når kolonneverdien endres, vil det føre til justering av rekkefølgen på hele tabellpostene, noe som vil bruke betydelige ressurser. Hvis applikasjonen din må oppdatere klyngede indekskolonner ofte, må du vurdere om du bør bygge indeksen som en klynget indeks.
17. Prøv å bruke numeriske felt, og prøv å unngå å designe felt som kun inneholder numerisk informasjon som tegn, noe som vil redusere ytelsen til spørringer og tilkoblinger, og øke lagringsoverhead. Dette er fordi motoren sammenligner hvert tegn i strengen én etter én når den behandler forespørsler og joins, mens for numeriske typer trenger den bare å sammenlignes én gang.
18. Bruk varchar/nvarchar i stedet for char/nchar så mye som mulig, fordi for det første kan lengre feltlagringsplass spare lagringsplass, og for det andre, for spørringer er søkeeffektiviteten i et relativt lite felt åpenbart høyere.
19. Ikke bruk velg * fra t noe sted, bytt ut "*" med en spesifikk liste med felt, og ikke returner felt som ikke er brukt.
20. Prøv å bruke tabellvariabler i stedet for midlertidige tabeller. Hvis tabellvariabelen inneholder store mengder data, merk at indeksen er svært begrenset (kun primærnøkkelindeksen).
21. Unngå hyppig opprettelse og sletting av midlertidige tabeller for å redusere forbruket av systemtabellressurser.
22. Midlertidige tabeller er ikke ubrukelige, og å bruke dem riktig kan gjøre noen rutiner mer effektive, for eksempel når du må referere til et datasett gjentatte ganger i en stor eller vanlig tabell. For engangshendelser er det imidlertid best å bruke en eksporttabell.
23. Når du oppretter en midlertidig tabell, hvis mengden data som settes inn samtidig er stor, kan du bruke select i i stedet for å opprette tabell for å unngå å forårsake et stort antall logger for å forbedre hastigheten; Hvis datamengden ikke er stor, bør du for å lette ressursene i systemtabellen først opprette tabellen og deretter sette inn.
24. Hvis en midlertidig tabell brukes, sørg for å eksplisitt slette alle midlertidige tabeller på slutten av den lagrede prosedyren, avkorte tabellen først, og deretter slippe tabellen, for å unngå at systemtabellen blir låst i lang tid.
25. Prøv å unngå å bruke markøren, fordi effektiviteten til markøren er dårlig, hvis dataene som behandles av markøren overstiger 10 000 linjer, bør du vurdere omskriving.
26. Settbaserte løsninger bør søkes for å løse problemer før man bruker markørbaserte eller midlertidige tabellmetoder, som ofte er mer effektive.
27. Som midlertidige tabeller er ikke markører ubrukelige. Å bruke FAST_FORWARD markører for små datasett er ofte bedre enn andre rad-for-rad-prosesseringsmetoder, spesielt hvis du må referere til flere tabeller for å hente dataene du trenger. Rutiner som inkluderer "total" i resultatsettet er vanligvis raskere enn de som utføres med markøren. Hvis utviklingstiden tillater det, kan både markørbaserte og mengdebaserte metoder prøves for å se hvilken som fungerer best.
28. Sett SETT NOCOUNT PÅ i starten av alle lagrede prosedyrer og triggere, og SET NOCOUNT OFF på slutten. Det er ikke nødvendig å sende DONE_IN_PROC meldinger til klienten etter at hver setning i den lagrede prosedyren og triggeren er utført.
29. Prøv å unngå store transaksjonsoperasjoner og forbedre systemets samtidighetskapasitet.
30. Prøv å unngå å returnere store data til klienten; hvis datavolumet er for stort, bør du vurdere om den tilsvarende etterspørselen er rimelig. |
Publisert på 27.01.2015 20:09:54
|
|
|
