1. Päringu optimeerimiseks peaksid vältima täielikku tabeli skaneerimist ja esmalt kaaluma veergude indeksi loomist, kus ja järjekorras.
2. Püüa vältida nullväärtushinnangut väljadele kus-klauslis, vastasel juhul loobub see mootorist indeksite kasutamisest ja teostab täieliku tabeli skaneerimise, näiteks:
Vali ID T-st, kus num on null
Võid määrata num-i vaikimisi väärtuseks 0, veenduda, et num-veerus pole nullväärtust tabelis, ja seejärel pärida nii:
Vali id t-st, kus num=0
3. Püüa vältida != või <> operaatorite kasutamist where-klauslis, vastasel juhul loobub mootor indeksite kasutamisest ja teeb täistabeli skaneerimise.
4. Püüdke vältida OR kasutamist where-klauslis tingimuse liitmiseks, vastasel juhul loobub see mootorist indeksite kasutamisest ja teeb täieliku tabeli skaneerimise, näiteks:
Vali id t-st, kus num=10 või num=20
Võite päringuid esitada nii:
Vali ID t-st, kus num=10
Liit kõik
Vali id t-st, kus num=20
5.in ja mitte sisse tuleks samuti kasutada ettevaatlikult, vastasel juhul võib see viia täieliku laua skaneerimiseni, näiteks:
Vali ID T-st, kus num in(1,2,3)
Pidevate väärtuste puhul ära kasuta in, kui saad kasutada nende vahel:
Vali ID T-st, kus number jääb vahemikku 1 kuni 3
6. Järgmine päring toob kaasa ka täieliku tabeli skaneerimise:
Vali ID T-st, kus nimi on näiteks '%ABC%'
Tõhususe parandamiseks kaalu täisteksti otsingut.
7. Kui kasutad parameetrit kus klauslis, põhjustab see samuti täieliku tabeli skaneerimise. Kuna SQL lahendab ainult lokaalseid muutujaid käitusajal, kuid optimeerija ei saa juurdepääsuplaanide valikut edasi lükata käitusajale; See tuleb valida kompileerimise ajal. Kui aga kompileerimise ajal luuakse ligipääsuplaan, on muutuja väärtus endiselt teadmata ja seetõttu ei saa seda kasutada indeksi valiku sisendina. Järgmised avaldused skaneeritakse täielikult:
Vali id t-st, kus num=@num
Saad sundida päringut kasutama indeksit:
Vali id t-st (indeksi(indeks(indeksi nimi)), kus num=@num
8. Püüa vältida väljade väljendamist where-klauslis, mis paneb mootori loobuma indeksite kasutamisest ja eelistama täistabeli skaneerimist. Näiteks:
Vali ID T-st, kus num/2=100
tuleks muuta järgmiselt:
Vali id t-st, kus num=100*2
9. Püüa vältida funktsioonioperatsioonide tegemist väljadele kus-klauslis, mis paneb mootori loobuma indeksite kasutamisest ja eelistama täistabeli skaneerimist. Näiteks:
vali id t-st, kus substring(name,1,3)='abc' --name id, mis algab abc-ga
Vali id t-st, kus datediff(day,createdate,'2005-11-30')=0--'2005-11-30' genereeritud ID
tuleks muuta järgmiselt:
Vali ID T-st, kus nimi on näiteks 'ABC%'
Vali id t-st, kus loodud>='2005-11-30' ja loodud<'2005-12-1'
10. Ära tee funktsioone, aritmeetilisi operatsioone ega muid avaldisi operatsioone "=" vasakul lõigus kus klauslis, vastasel juhul ei pruugi süsteem indeksit õigesti kasutada.
11. Kui indeksvälja kasutatakse tingimusena, siis kui indeks on komposiitindeks, tuleb indeksi esimene välja kasutada tingimusena, et süsteem kasutab indeksit, vastasel juhul indeksit ei kasutata ning väljade järjekord peaks olema võimalikult kooskõlas indeksi järjekorraga.
12. Ära kirjuta mõttetuid päringuid, näiteks genereeri tühja tabelistruktuuri:
vali col1,col2 #t t-st, kus 1=0
See kood ei tagasta tulemuste hulka, kuid tarbib süsteemi ressursse, seega tuleks see muuta selliseks:
loo tabel #t(...)
13. Sageli on hea valik asendada sellega, et on olemas:
vali num a-st, kus num sisse (vali num b-st)
Asenda järgmise väitega:
vali num a-st, kus eksisteerib (vali 1 b-st, kus num=a.num)
14. Kõik indeksid ei kehti päringute jaoks, SQL põhineb tabelis olevatel andmetel päringu optimeerimiseks; kui indeksiveerus on suur hulk andmete dubleerimist, ei pruugi SQL-päringud indeksit kasutada, näiteks tabelis on väli sugu, mees, naine on peaaegu pool igaühest, ja isegi kui indeks põhineb sool, ei mängi see päringute efektiivsuses rolli.
15. Mida rohkem indekseid ei ole, seda parem, indeks võib kindlasti parandada vastava valiku efektiivsust, kuid vähendab ka sisestamise ja uuendamise efektiivsust, sest indeks võib sisestamisel või uuendamisel uuesti üles ehitada, seega tuleb indeksi loomist hoolikalt läbi mõelda, sõltuvalt konkreetsest olukorrast. Parim on mitte hoida tabelis rohkem kui 6 indeksit, ja kui neid on liiga palju, kaalu, kas on vaja indekseid ehitada mõnele harva kasutatavale veerule.
16. Vältige klasterdatud indeksiandmete veergude uuendamist nii palju kui võimalik, sest klasterdatud indeksiandmete veergude järjekord on tabelikirjete füüsiline salvestusjärjekord ning kui veeru väärtus muutub, viib see kogu tabelikirjete järjekorra kohandamiseni, mis kulutab märkimisväärseid ressursse. Kui teie rakendus peab klasterdatud indeksiveerge sageli uuendama, peate kaaluma, kas ehitada indeks klasterdatud indeksina.
17. Proovi kasutada numbrilisi välju ja mitte kujundada välju, mis sisaldavad ainult numbrilist infot tähemärkidena, mis vähendab päringute ja ühenduste jõudlust ning suurendab salvestuskoormust. See on tingitud sellest, et mootor võrdleb iga stringi märki ükshaaval, kui töödeldakse päringuid ja liitumisi, samas kui numbriliste tüüpide puhul tuleb seda võrrelda vaid üks kord.
18. Kasuta varchar/nvarcharit char/nchar asemel nii palju kui võimalik, sest esiteks võib pikem välisalvestusruum säästa salvestusruumi ja teiseks, päringute puhul on otsinguefektiivsus suhteliselt väikeses väljas ilmselgelt kõrgem.
19. Ära kasuta *from t kusagilt, asenda "*" kindla väljade nimekirjaga ja ära tagasta ühtegi välja, mida ei kasutata.
20. Proovi kasutada tabelimuutujaid ajutiste tabelite asemel. Kui tabelimuutuja sisaldab suurt hulka andmeid, pane tähele, et indeks on väga piiratud (ainult peamine võtmeindeks).
21. Vältige ajutiste tabelite sagedast loomist ja kustutamist, et vähendada süsteemitabeli ressursside tarbimist.
22. Ajutised tabelid ei ole kasutuskõlbmatud ning nende õige kasutamine võib muuta mõned rutiinid tõhusamaks, näiteks kui pead korduvalt viitama andmekogule suures tabelis või tavapärases tabelis. Kuid ühekordsete sündmuste puhul on kõige parem kasutada eksporditabelit.
23. Ajutise tabeli loomisel, kui korraga sisestatud andmete hulk on suur, siis saad kasutada select into funktsiooni loo tabeli asemel, et vältida suurt logide arvu kiiruse parandamist; Kui andmemaht pole suur, siis süsteemitabeli ressursside lihtsustamiseks tuleks esmalt luua tabel ja seejärel lisada.
24. Kui kasutatakse ajutist tabelit, kustuta kindlasti kõik ajutised tabelid salvestatud protseduuri lõpus, lühenda tabel esmalt ja seejärel eemalda tabel, et vältida süsteemitabeli pikaajalist lukustamist.
25. Püüa vältida kursori kasutamist, sest kursori efektiivsus on kehv; kui kursori poolt juhitav andmemaht ületab 10 000 rida, peaksid kaaluma ümberkirjutamist.
26. Komplektipõhiseid lahendusi tuleks otsida probleemide lahendamiseks enne kursoripõhiste või ajutiste tabelimeetodite kasutamist, mis on sageli tõhusamad.
27. Nagu ajutised tabelid, ei ole kursorid kasutuskõlbmatud. FAST_FORWARD kursorite kasutamine väikeste andmekogumite jaoks on sageli parem kui teised ridapõhised töötlemismeetodid, eriti kui pead viitama mitmele tabelile, et saada vajalikke andmeid. Rutiinid, mis sisaldavad tulemuste hulka "total", on tavaliselt kiiremad kui need, mis täidetakse kursoriga. Kui arendusaeg lubab, saab proovida nii kursoripõhiseid kui ka komplektipõhiseid meetodeid, et näha, kumb töötab paremini.
28. Pane SET NOCOUNT SISSE kõigi salvestatud protseduuride ja päästikute alguses ning SET NOCOUNT OFF lõpus. Pärast iga salvestatud protseduuri ja käivitaja käivitamist ei ole vaja saata kliendile DONE_IN_PROC sõnumeid.
29. Püüa vältida suuri tehinguoperatsioone ja parandada süsteemi paralleelsuse võimekust.
30. Püüa vältida suurte andmete tagastamist kliendile, kui andmemaht on liiga suur, peaksid kaaluma, kas vastav nõudlus on mõistlik. |
Postitatud 27.01.2015 20:09:54
|
|
|
