1. Kyselyn optimoimiseksi kannattaa välttää täyttä taulukon skannausta ja ensin harkita indeksin luomista sarakkeista, joissa ja järjestyksessä.
2. Yritä välttää null-arvon arviointia kentille where-lauseessa, muuten moottori luopuu indeksien käytöstä ja suorittaa täydellisen taulukon skannauksen, kuten:
Valitse id T:stä, missä num on nolla
Voit asettaa num-arvon oletusarvoksi 0, varmistaa ettei num-sarakkeessa ole nollaarvoa taulukossa, ja sitten tehdä kyselyn näin:
Valitse id t:stä, missä num=0
3. Yritä välttää !=- tai <>-operaattoreiden käyttöä where-lauseessa, muuten moottori luopuu indeksien käytöstä ja suorittaa koko taulukon skannauksen.
4. Sinun tulisi välttää OR:n käyttöä where-lausekkeessa ehtojen liittämiseen, muuten moottori luopuu indeksien käytöstä ja suorittaa täydellisen taulukon skannauksen, kuten:
Valitse id t:stä, missä num=10 tai num=20
Voit kysyä näin:
Valitse ID t:stä, missä num=10
Union all
Valitse ID t:stä, missä num=20
5.in ja ei-sisään tulee myös käyttää varoen, muuten se johtaa täydelliseen taulukkoskannaukseen, kuten:
Valitse id t:stä, missä num in(1,2,3)
Jatkuvien arvojen kohdalla älä käytä in:ää, jos voit käyttää välissä:
Valitse ID T:stä, missä numero välissä 1–3
6. Seuraava kysely johtaa myös täydelliseen taulukkoskannaukseen:
Valitse ID T:stä, missä nimi kuten '%ABC%'
Tehokkuuden parantamiseksi harkitse kokotekstihakua.
7. Jos käytät parametria where-lauseessa, se aiheuttaa myös täydellisen taulukon skannauksen. Koska SQL ratkaisee paikalliset muuttujat vain ajonaikaisesti, mutta optimointiohjelma ei voi siirtää pääsysuunnitelmien valintaa ajonaikaiselle; Se täytyy valita käännösvaiheessa. Kuitenkin, jos käyttösuunnitelma perustetaan käännösvaiheessa, muuttujan arvo on edelleen tuntematon, eikä sitä siksi voida käyttää syötteenä indeksin valinnassa. Seuraavat lausunnot skannataan kokonaisuudessaan:
Valitse id t:stä, missä num=@num
Voit pakottaa kyselyn käyttämään indeksiä sen sijaan:
Valitse id t:stä (index(index(index name)), missä num=@num
8. Yritä välttää kenttien ilmaisemista where-lauseessa, jolloin moottori luopuu indeksien käytöstä ja siirtyy täydelliseen taulukkoskannaukseen. Esimerkiksi:
Valitse ID t:stä, missä num/2=100
tulisi muuttaa muotoon:
Valitse ID t:stä, missä num=100*2
9. Yritä välttää funktio-operaatioiden tekemistä kentillä where-lauseessa, jolloin moottori luopuu indeksien käytöstä ja siirtyy täydelliseen taulukkoskannaukseen. Esimerkiksi:
Valitse id t:stä, missä substring(name,1,3)='abc' --name id, joka alkaa abc:llä
Valitse id t:stä, missä datediff(day,createdate,'2005-11-30')=0--'2005-11-30' generoitu ID
tulisi muuttaa muotoon:
Valitse ID T:stä, missä nimi on 'ABC%'
Valitse id t:stä missä createdate>='2005-11-30' ja createdate<'2005-12-1'
10. Älä suorita funktioita, aritmeettisia operaatioita tai muita lausekkeiden operaatioita "=":n vasemmalla puolella missä lauseessa, muuten järjestelmä ei välttämättä pysty käyttämään indeksiä oikein.
11. Kun indeksikenttää käytetään ehtona, jos indeksi on yhdistetty indeksi, indeksin ensimmäinen kenttä on käytettävä ehtona, jotta järjestelmä käyttää indeksiä, muuten indeksiä ei käytetä, ja kenttien järjestys on mahdollisimman yhdenmukainen indeksin järjestyksen kanssa.
12. Älä kirjoita merkityksettömiä kyselyjä, kuten tyhjän taulukon rakenteen luomista:
Valitse col1,col2 #t t:stä, missä 1=0
Tämä koodityyppi ei anna tulosjoukkoa, mutta kuluttaa järjestelmän resursseja, joten se tulisi vaihtaa tällaiseksi:
luo taulukko #t(...)
13. Monesti on hyvä valinta korvata olemassa olevalla tavalla:
Valitse num a:sta, missä num sisään (valitse num b:stä)
Korvaa seuraavalla lauseella:
Valitse num a:sta, missä on olemassa (valitse 1 b:stä, missä num=a.num)
14. Kaikki indeksit eivät ole päteviä kyselyille, SQL perustuu taulukon dataan kyselyn optimoimiseksi, kun indeksisarakkeessa on paljon datan duplikaatiota, SQL-kyselyt eivät välttämättä käytä indeksiä, esimerkiksi taulukossa on sukupuoli, mies, nainen on lähes puolet kumpikin, ja vaikka indeksi perustuisi sukupuoleen, sillä ei ole merkitystä kyselyn tehokkuudessa.
15. Mitä enemmän indeksejä ei ole, sitä parempi, indeksi voi varmasti parantaa vastaavan valinnan tehokkuutta, mutta se myös heikentää lisäyksen ja päivityksen tehokkuutta, koska indeksi voidaan rakentaa uudelleen lisäyksen tai päivityksen yhteydessä, joten indeksin rakentamista on harkittava huolellisesti tilanteen mukaan. On parasta, ettei taulukossa ole enempää kuin 6 indeksiä, ja jos niitä on liikaa, harkitse, onko tarpeen rakentaa indeksejä joihinkin harvoin käytettyihin sarakkeisiin.
16. Vältä klusteroitujen indeksidatasarakkeiden päivittämistä mahdollisimman paljon, koska klusteroitujen indeksidatasarakkeiden järjestys on taulukkotietueiden fyysinen tallennusjärjestys, ja kun sarakkeen arvo muuttuu, se johtaa koko taulutietueiden järjestyksen säätämiseen, mikä kuluttaa huomattavasti resursseja. Jos sovelluksesi täytyy päivittää klusteroituja indeksisarakkeita usein, sinun täytyy harkita, pitäisikö indeksi rakentaa klusteroiduksi indeksiksi.
17. Yritä käyttää numeerisia kenttiä, äläkä suunnittele kenttiä, jotka sisältävät vain numeerista tietoa merkkeinä, mikä heikentää kyselyjen ja yhteyksien suorituskykyä ja lisää tallennuskustannuksia. Tämä johtuu siitä, että moottori vertaa jokaista merkkijonon merkkiä yksi kerrallaan kyselyitä ja liitoksia käsitellessään, kun taas numeerisissa tyypeissä sitä tarvitsee verrata vain kerran.
18. Käytä mahdollisimman paljon varchar/nvarcharia char/ncharin sijaan, koska ensinnäkin pidempi kenttätallennustila säästää tallennustilaa, ja toiseksi kyselyissä haun tehokkuus suhteellisen pienellä kentällä on selvästi korkeampi.
19. Älä käytä valitse * from t mistään, korvaa "*" tietyllä kenttälistalla, äläkä palauta kenttiä, joita ei käytetä.
20. Yritä käyttää taulukkomuuttujia väliaikaisten taulukoiden sijaan. Jos taulukkomuuttuja sisältää suuren määrän dataa, huomaa, että indeksi on hyvin rajallinen (vain ensisijainen avainindeksi).
21. Vältä väliaikaisten taulukoiden toistuvaa luomista ja poistamista järjestelmätaulujen resurssien vähentämiseksi.
22. Väliaikaiset taulukot eivät ole käyttökelvottomia, ja niiden oikea käyttö voi tehdä joistakin rutiineista tehokkaampia, esimerkiksi kun sinun täytyy toistuvasti viitata dataan suuressa taulukossa tai yleisesti käytetyssä taulukossa. Kertaluonteisissa tapahtumissa on kuitenkin parasta käyttää vientitaulukkoa.
23. Väliaikaista taulua luodessa, jos kerralla syötettävän datan määrä on suuri, voit käyttää select-taulukkoa create-taulukon sijaan välttääksesi suuren lokimäärän nopeuden parantamisen; Jos datamäärä ei ole suuri, järjestelmätaulun resurssien helpottamiseksi sinun tulisi ensin luoda taulu ja sitten lisätä se.
24. Jos väliaikaista taulua käytetään, poista kaikki väliaikaiset taulut tallennetun prosessin lopussa, katkaise ensin taulu ja sitten poista taulu, jotta järjestelmätaulu ei jää lukitsetuksi pitkäksi aikaa.
25. Yritä välttää kursorin käyttöä, koska kursori on heikko; jos kursorin ohjaama data ylittää 10 000 riviä, kannattaa harkita uudelleenkirjoittamista.
26. Joukkopohjaisia ratkaisuja tulisi etsiä ongelmien ratkaisemiseksi ennen kursoripohjaisten tai väliaikaisten taulukkomenetelmien käyttöä, jotka ovat usein tehokkaampia.
27. Kuten väliaikaiset taulukot, kurssorit eivät ole käyttökelvottomia. FAST_FORWARD kursorien käyttö pienille aineistoille on usein parempi kuin muut rivikohtaiset käsittelymenetelmät, erityisesti jos sinun täytyy viitata useisiin tauluihin saadaksesi tarvittavan datan. Rutiinit, jotka sisältävät "total" tulosjoukkoon, ovat yleensä nopeampia kuin ne, jotka suoritetaan kursorilla. Jos kehitysaika sallii, voidaan kokeilla sekä kursori- että joukkopohjaisia menetelmiä, jotta nähdään, kumpi toimii paremmin.
28. Aseta SET NOCOUNT PÄÄLLE kaikkien tallennettujen proseduurien ja laukaisujen alussa, ja ASETA NOCOUNT POIS päältä lopussa. Ei ole tarvetta lähettää DONE_IN_PROC viestejä asiakkaalle jokaisen tallennetun proseduurin ja laukaisun suorittamisen jälkeen.
29. Pyri välttämään suuria transaktiotoimintoja ja parantamaan järjestelmän rinnakkaiskapasiteettia.
30. Yritä välttää suurten tietojen palauttamista asiakkaalle; jos datamäärä on liian suuri, sinun tulisi harkita, onko vastaava kysyntä kohtuullinen. |
Julkaistu 27.1.2015 20.09.54
|
|
|
