TechRepublic’ s free SQL Server newsletter, toimitetaan joka tiistai, sisältää käytännön vinkkejä, jotka auttavat sinua tulemaan taitavammaksi tämän tehokkaan relaatiotietokannan hallintajärjestelmän kanssa. Tilaa automaattisesti jo tänään!
yleisesti hyväksytty viisaus tallennetuista menettelyistä (tai ketjupyöristä) on,että koska SQL voi optimoida ja kääntää ne, ne toimivat nopeammin kuin vastaavat SQL-lausekkeet, jotka suoritetaan Queryanalysaattorilla (tai ehkä välitetään jostain front-end-sovelluksesta, kuten Web-sivulta tai VB-ohjelmasta). Tämä pitää jossain määrin paikkansa.
Ensin pitää tietää, mitä SQL Server tekee uudella sprocilla. Luomishetkellä se tarkistaa syntaksin. Jos se ei löydä virheitä, se lisää sproc: n järjestelmätaulukoihin: sysobjects,sysdepends ja syscomments (jälkimmäinen tallentaa sproc: n rungon). Oletuksena, se ei käännä sproc luomisen aikaan.
ensimmäisen sproc-suorituksen jälkeen SQL Server optimoi ja kokoaa sen. Tämä on, kun SQL Server laatii queryplan ja tallentaa sen sen menettely välimuisti. Myöhemmissä invocations, SQL looksin välimuisti ensin, löytää sproc siellä, anddoesn ’ t kääntää sitä. Jos sproc ei ole välimuistissa,SQL Server kokoaa sen ja sijoittaa sen välimuistiin.
oma kokemukseni KÄÄNTEISVALINNASTA
jokin aika sitten tuin hakusivua, jonka avulla sen käyttäjät voivat hakea millä tahansa useammasta sarakkeesta. Sitten sivun kutsutaan sproc, kulkee parametri osoittaa, mikä sarake tosearch. Olen tutkinut parametrin käyttäen CASE block, ja sitten suoritetaan yksi ofseveral kyselyt, riippuen sarakkeen etsiä.
tiesin, että jotain oli vialla, kun aloin testata väittämääni tallennettua menettelyä. Teoriassa jokaisen haun suorituskyvyn pitäisi olla vähintään suunnilleen sama, mutta niin ei tapahtunut. Kun suoritin useita hakuja, järjestyksestä riippumatta, ensimmäinen olisi nopea, ja seuraavat haut olivat paljon hitaampia.
lopulta tajusin, että ensimmäisen kerran kun toimenpidettä kutsuttiin, laadittiin kyselysuunnitelma ja tallennettiin välimuistiin. Niin kauan kuin etsin sitä tiettyä palstaa, kaikki toimisi odotetusti. Heti kun vaihdoin palstaa, suorituskyky kuitenkin romahti. Miksi näin kävi?
ensimmäinen suorittamani haku loi välimuistiin kyselysuunnitelman ja storeditin. Esimerkiksi, jos olisin etsinyt palstan Tilauspäivämäärästä. Jos olen vaihtanut haku CompanyName sarake, SQL sokeasti käyttää välimuistissa queryplan, etsivät kohdeyhtiön nimi käyttäen OrderDateindex. Ei ihme, että suorituskyky romahtaisi niin dramaattisesti.
korjaus on melko yksinkertainen. Suoritin ketjuratkaisun käänteisellä valinnalla:
EXEC MySproc_Select '12/31/2004' WITH RECOMPILE
Tämä kertoo SQL Serverin heittävän pois olemassa olevan kyselysuunnitelman ja rakentavan toisen–mutta vain tämän kerran.
voit myös lisätä WITH RECOMPILEN suoraan storedprosessiin juuri ennen AS-avainsanaa. Tämä kertoo SQL Server heittää pois thequery suunnitelma jokaisen suorittamisen sproc.
on olemassa myös kolmas vaihtoehto. Olisin voinut luoda erillisen sproc: n jokaiselle hakumenetelmälle, ja sitten päättää, kumpi suoritetaan salkun sisällä. Näin osapyörien kanssa yhdistetty kyselyplanssi jää välimuistiin, jossa SQL voi hyödyntää niitä. Koska jokainen ketjupyöräsiirrettiin täsmälleen yhteen sarakkeeseen, ei ole tarvetta kääntää uudelleen.
SQL Serverin kyky optimoida ja kääntää varastointiprosessi on suuri, mutta jos et ole varovainen, se voi purra sinua, kun ainakin odotat sitä. Nyt kun osaat käsitellä ongelmaa, ehkä omassa tietokannassasi on muutama tilanne, jotka haluat ehkä tarkistaa.